In part 1 & part 2 of this series I did a brief history of software development as I see it and how that impacted the people who were coming into the industry, I would like to finally get to the topic I set out to write about. How the heck to you manage these people?

Based on my hypothesis that we are operating in a new digital world where the rules don’t apply the same way as they do in the physical world, there are a few things I think that make managing these people tough.

Why Its hard

I think managing people is just hard. I hear it from all industries. However, I think there are some unique challenges that are present in the software engineering manager role.

Writing code is an art and a science

As we talked about in part 2, writing software is as much an art as it is a science. Each developer has their own writing style and if you work with people long enough you can even begin to pick out who wrote the code based on the style. This makes it hard to develop metrics and standards that are extremely prescriptive. Prescriptive standards favor the science aspect of writing code and will stifle the art aspect of it.

Developers can work from anywhere now

To office or not to office? That is the question.

It's clear that remote work is here to stay. It was inevitable that it would become more popular over time. Covid sped up that timeline by about 10 years. It forced everyone to develop the capability, and now that the capability is there, it's hard to find any excuses.

It's hard to manage people in a completely remote setting. It takes a lot of trust to know that while people are not being watched, they are putting in effort. Even if people are putting in the effort, it's hard to verify that some of the more senior-level activities like code review and mentoring are happening since you can't observe it.

The digital world is not the physical world

As I talked about in part 1, we are in a whole new world that doesn’t have the same rules as the physical world. But, just because you can do something doesn’t mean you should. In the digital world, there are so many crazy things that you could do to solve a problem. These “clever” solutions often end up being a burden to the team because they were a little too clever and ended up being hard to understand for the people coming after.

Developers like to interface with computers, not people

I have a longer post about trade-offs that deep dives into this topic, but the obvious trade-off of being really good at working with computers is that someone might not be good at working with people. Some of your best developers can be some of the quirkiest and hardest to communicate with. This is so common that it has become the stereotype for our industry, particularly among men.

Perverse Incentives

Almost everything that tracks developers can fall victim to 2nd and 3rd order consequences. Creating software is a complex process, and it can be easy to assume that there is a silver bullet metric that can cause everyone to align on the right thing. More likely than not, that will align them to that one thing but create chaos in other areas. Almost every code metric you monitor will create a perverse incentive if you tie it to performance.

Managing Software Developers

This is by no means a comprehensive list, and I lay no claim to having figured all of this out. However, given the challenges presented, I find these things to be helpful.

Team Metrics

Because people need to perform multiple roles at once, the best way to measure their performance is not against the individual but against the team. Developers need to wear many hats, but they will likely specialize and find a niche. Like elite military units, everyone needs to be competent, but everyone has a special way that they contribute to the team. Individual metrics can inadvertently cause people to prioritize only one aspect of the job. Team metrics focus people on doing all of the things necessary to ensure the success of the team.

The team also creates a checks and balances system against perverse incentives. In order to game the metric, everyone has to do it, and that is harder to pull off because people have to be vocal about their intent.

Do Things in the Open

Because remote work is so prevalent, I encourage more people to do things in the open. By this, I mean that comments and feedback should be public. Code review should be more like open source where it all takes place in the PR and not in private meetings or chats. Without a paper trail, it becomes almost impossible to validate that certain tasks are being done. So, I encourage everyone to do more in public.

Trust but Verify

Individual metrics should be used to inform but not tied to performance. Managers need a way to get an indicator that they need to dive into the weeds on something. That is what individual metrics are good for. It's a trailing indicator that something has gone off the rails. Use metrics as a signal to get personally involved in a process.

Connect Them to the Bigger Picture

We have heard it a million times, “start with why”. But the reason it is repeated is because it is important. If developers can see how their little task connects to the larger mission, it makes it much more meaningful. I don't think people get burnt out because the work is hard or even if it takes long hours. They get burnt out when that effort is meaningless. It's important to align your team to the mission of your company.

It is also important to align the company to your team. If the company isn’t connecting its success back to the team in a meaningful way, then there won't be true alignment. If, when the company succeeds, the team benefits, you will find that people will enjoy their work and find it extremely meaningful.

I talk a lot about the importance of embracing stress in your life. That is easier said than done. As you begin to embrace stress you will need some tools to help you, because putting stress on yourself is not easy to do. You need something that can help you mentally take on the stress. The most helpful thing for me has been the contrast principle which I lay out in this post.

The Principle

If you are looking to enjoy life more I have found one principle that is guaranteed to work. In fact people who live their lives by this principle probably don't even know they are doing it. They have found it organically and don't need to articulate it but if they could put it into words they would realize that what they are feeling is exactly this. I call it the contrast principle and it is a fundamental to life. The principal is this:

Something ordinary can become extraordinary when it is preceded by something stressful.

I know this is an oversimplification but it needs to be simple and memorable. Its also better understood through stories and illustrations because on first reading it probably doesn’t make sense. But trust me, you cant help but fill in the stories with your own times that you encountered this principle.

How I First Discovered the Principle

How I discovered this principle is rather unglamorous. Its not some life changing adventure I had that altered my life but a series of ordinary events. I grew up working on staff at a summer camp. My favorite job was to run the chainsaw. We had acres of forest and there was more things to cut than I ever had time for. I would spend hours in the 100 degree Kansas heat cutting wood and getting covered in dirt, sweat, oil and woodchips. My limbs would be vibrating and my muscles aching. I would put up my saw at the end of the day, rinse off and jump into the pool. The kids would be coming from the snack shack hopped up on sugar, laughing and having a generally good time. They were enjoying the pool but I was enjoying it 100x more.

Why? Because of the contrast.

I didn't have a name for it, I just felt it. I didn't even realize I what I was doing. One day the director pointed it out. By working as hard as I did I was experiencing a feeling that only a rare few get to experience. That feeling is a contrast between two states of being. He said remember in life that a shower always feels better when you are sore, sweaty and dirty.

I next encountered the feeling while helping my friend move out of his grandma's basement. He had been renting the basement from her for a bit but was moving on. In typical single guy fashion the room was less than tidy. In fact it was a wreck. We spent the whole day moving and cleaning. As I was turning off the light I looked back over the room and was so pleased with it. I had spent many of my childhood days in that room and had never once thought about it in that way. But having just taken it from where it was back to normal I was very pleased just to look at the room. It was in that moment that I realized I wasn't pleased with the room but with the contrast of where it had been to where it was. It was then that I coined the phrase "The Contrast Principle"

Life in the Contrasts

To say that I altered my life completely to embrace this principle would be a stretch. But I was tuned into it. I began to notice it everywhere:

• The Sysco burger I had after running out of food in the Grand Canyon was the best I have ever had.

• Drinking water after running out of it in the Arizona desert was the best tasting drink I could imagine.

• Pizza after 3 days of climbing high mountain peaks in Colorado tastes better than any pizza I could dream up.

• Hot tubs are way better after hard workouts when your muscles are sore and aching.

I could go on and on. In fact your brain has probably started listing off its own.

How to Live Life in the Contrasts

I like to joke that a shower just doesn't feel that good after a hard day of watching Netflix on the couch. If you want to turn the ordinary events in your life, like a meal or a shower, into extraordinary ones you have to get out and do things. You have to live in a way that creates contrast. Get sweaty, dirty, sore, hungry and tired. Only then will the contrast be possible.

I chose the word "bad" for a reason because it can apply even to really terrible things that no one should have to go through. I cant speak from personal experience here but people who have had extreme trauma in their life can let it cripple them or live in the contrast of it. People who choose the latter are some of the most driven and enjoyable people to be around. To them just waking up in the morning can be an incredible experience.

So to live life in the contrast you must do 2 things. First you must choose to do difficult things in your life. You must resist the appeal of the couch and the life of ease. You have to work hard. And secondly you have to choose to live in the contrast of traumatic events. Rather than letting them cripple you, let them be the fuel that lets you enjoy the very air you are breathing.

So go, and live life in the contrasts.

If you liked this, consider subscribing to my Substack. I publish an article about software engineering and software engineering management every Tuesday. If you want even more, consider joining my paid content where I am writing a course in real time about making the jump from developer to manager

Subscribe now

Leadership is hard and it takes a long time to get good at it.

One reason is that you cant take any advice or principle to its extreme. If you do the benefit goes away. For example a leader should be detail oriented but if you pay attention to every detail you will end up a micro manager.

Another reason is because there is often contradicting advice on leadership. Its possible to see the exact opposite advice in back to back posts on social media. The common LinkedIn example I see is: “People are your best asset you need to treat them like family” vs “Stop saying your company is a family”

This two points are actually related. You see, leadership is a dichotomy. You have to hold two principles in tension and find the right balance in the middle. You cant go to either extreme.

You have to be detail oriented and not have to have every detail.

You need to develop good relationships with the people you lead but not so much that they forget who is in charge.

This all takes observation and discretion and through observation and discretion you can create the right balance.

Jocko Willink was the first person to make me excited about leadership. He wrote the book “Extreme Ownership” about taking ownership of everything in your work and in your life. Naturally many people took the lessons he was teaching to the extreme. They assumed that if a little bit was good, a lot was better.

He followed that book up with “The Dichotomy of Leadership”. In this book he was trying to show that leadership was actually a balancing act between two things, a dichotomy. You had to find the right balance. After his book came out, he posted these 12 dichotomies of leadership:

1. Confident but not cocky

2. Courageous but not foolhardy

3. Competitive but a gracious loser

4. Attentive to details but not obsessed by them

5. Strong but have endurance

6. A leader and a follower

7. Humble and not passive

8. Aggressive and not overbearing

9. Quiet not silent

10. Calm but not robotic, logical but not devoid of emotions

11. Close with the troops but not so close that one becomes more important than the other or than the good of the team, not so close that they forget who is in charge

12. Able to execute extreme ownership when exercising decentralized command

In this post Im going to give my commentary on each of the 12 as it pertains to being a development manager.

Confident but not cocky

In the tech world I see lots of people struggling to even be confident. I wrote about this in the Antidote to Imposter Syndrome. The core of that message was to build evidence not confidence.

Confidence comes from evidence that you have done this task before and have the receipts to prove it. You build a rock solid set of examples where you have what it takes to be in the game.

Mix that evidence with a little ego and you have a recipe for cockiness.

You see, the evidence is for you. You need to know you can do it. Once you feel like that evidence is for everyone else you have overcorrected. Flaunting your experience wont build you friendships and wont elicit new ideas. People wont give you their opinion if they think yours is already made up.

The dichotomy is to build the evidence and the confidence without feeling like you have arrived and that everyone can benefit from your experience.

Courageous but not foolhardy

Never give up! Never Surrender! - Galaxy Quest Crew

It takes a lot of courage to keep going when things get tough. You may be beat down and struggling to even see how you will pull it off. You may wake up every day and throw the white flag but you keep going. Those are the kinds of people we all want to work with.

But…

What if you are in the wrong fight? What if the battle cant be won?

This dichotomy is one of the most difficult because sometimes the right thing is to take a tactical retreat. If the work you are engaged in isnt going to move the needle on anything of substance why do it?

It takes discretion to know when you are being weak and need to be courageous and keep fighting or if you are in a losing battle and need to retreat back to conserve your effort for a fight you can win.

Dont be foolhardy and always complete what you start, because you may have started down the wrong path.

Competitive but a gracious loser

I love the tradition of shaking hands after a chess game. Even if the people don't feel it, it is symbolic of this principle. You need to play with all you've got, but when it is over, shake their hand.

They say in sales that "no" is a good thing. Not that you want to hear it that often, but it is information. If you can understand why you get a "no," you will learn a bit about your product.

Like getting to “no”, losing is information. What went wrong? What do you need to improve? How can you come back to the game more prepared?

Similar to the dichotomy: be confident but not cocky, your ego is what takes your competitiveness over the edge. Check your ego and accept the loss as good information for the next time.

Attentive to details but not obsessed by them

I am admittedly not a detail oriented person. I like the big picture and leaving the details up to other people. That means that I “tilt” in the direction of not being attentive to details. I am very good about not being obsessed by them.

I like being surrounded by detail oriented people. They look at the details and draw my attention to them. In this case I use other people to pull myself into the middle. A lot of my failures as a leader come down to missed details. Its a big area of improvement.

If you are a detail oriented person, you probably excel at your job as a individual contributor. Your work always has that polish that mine usually lacked 😁. However, once you are in leadership you will find that being deep in the weeds on the details will cause you to miss things. This is encapsulated in the colloquial phrase, “Cant see the forrest from the trees”.

If you dive in on the details and try to manage every detail you will lose sight of the big picture and fail to lead strategically. You will move from proactive to reactive since you are not looking up at the horizon but down at your feet.

Strong but have endurance

Strength and endurance immediately call to mind the physical. And indeed you have to have both in the physical world. If you are extremely strong but get winded climbing a flight of stairs, that is an issue.

In the software world I find I have more strength than endurance, but I am getting better at the endurance part. Strength is being able to jump in and solve an issue really quickly. Thinking on your feet and working late into the night. I love that stuff.

Endurance is working through a 6 month migration with customers and other parts of the company. That sounds miserable. However, most things cant be solved with a one night heroic endeavor. Most work is long and slow. The code might even be the easy part but coordinating with other departments and getting customers to move creates a marathon.

A leader and a follower

I would hazard a guess that we are all decent at following when it comes to the classical top down structure. We listen to our boss and work to do what they say. That is the core of how the business world works.

I recently heard a talk by a CEO and he said that his head of HR came to him and said, “We need to hire 12 people in the next 30 days. What should I do?”

His response surprised me.

“Figure it out, I didn’t hire you to tell you what to do. I hired you to tell ME what to do.”

We can follow if its our boss but what if its someone who reports to us? If you delegate something and expect the person to own it and they say, “Great! I need you to talk to so and so and get us this resource” Can you follow their lead?

Being a follower isnt just top down. Its being able to put your ego in check and let someone else call the shots, regardless of where they sit on the management chain.

Humble and not passive

I have a confession. I am a terrible dancer. I really want to be a better one, dancing looks fun and is a good social skill. I have also had plenty of opportunities to learn but I have been too prideful to display my two left feet to the world. Its not humility its passivity.

The hardest thing on your pride is trying new things. Embracing the beginner mindset. For people who are successful at life, becoming a beginners is tough. It hits the pride so hard that they often avoid it.

If you keep doing things that you are not good at and other people are better at you will constantly be reminded to keep your own pride in check at the things you are good at. You have a lot of things to be proud of but so what, switch the domain and you will be back to basics. There is a lot to learn in life.

Dont hold your accomplishes up over people and dont let your lack of skill keep you from trying.

Aggressive and not overbearing

“Default Aggressive” is another Jockoism. Your first instinct should be to go hard after a problem. However the saying isnt “always aggressive”. People who are always aggressive are not fun to be around. Everything is a competition, every word and action is trying to win a battle.

Everything is serious.

These kinds of people often get chided back from others with, “Boy, you must be fun at parties”. And rightfully so. They have no chill, there is no off switch.

Its a hard balance to be default aggressive and yet still be fun at parties. Likewise, if you are always chill, you may be losing because you need some aggressive action to get the ball moving.

Quiet not silent

As I have gotten more experienced as a leader I have found lots more value in the skill of listening. People assume that as you gain more leadership you have more answers. The truth is that the more that is under your leadership, the more you have to listen for answers.

I like what one CEO said to his head of HR who brought him a problem, “Figure it out, I didn’t hire you to tell you what to do. I hired you to tell ME what to do.”

A good CEO hires the right people and listens to them.

However there is a time to speak. You have to speak in order to lead. Your cant just listen. Finding that balance is hard. Im guessing most of us tilt towards the speaking side. We love the sound of our own voice.

However, I have managed people who I have to encourage to speak up. They are too willing to just listen and are not engaged in solving the problems facing the organization.

Listen intently but if you have something to say, you need to say it.

Calm but not robotic, logical but not devoid of emotions

I don't want to stereotype my industry too much, but if you are like me, part of the reason you got into computers is because you love logic, you love robots, and you have no problem being devoid of emotions.

That last part was from my wife 😁

Being calm and detaching from your emotions is a very important skill. Decision-making is always better when you are detached. Emotions cloud your thinking and can cause you to make an irrational decision that seems rational at the time. Being able to set them aside for a time to focus on the best decision for the current problem is something to aspire to.

On the flip side, emotions are how we connect with other humans. Shared emotions are some of the strongest bonds. People who are in touch with their emotions and the emotions of others are much better at empathy and building relationships. Detaching too far can cause you to become a robot devoid of things that make life meaningful.

Of all the dichotomies, this one is the most important to keep in balance and possibly the hardest.

Close with the troops but not so close that one becomes more important than the other or than the good of the team, not so close that they forget who is in charge

Its very important to have close relationships with the people you manage. This is synonymous with trust. You trust someone because you have a close relationship with them and you know they have your best interests at heart.

Its inevitable that those relationships will at some point come in conflict. If you have become too close you might have a temptation to choose the relationship over dealing with the conflict, even at the expense of the team.

Your friend might need to correct a behavior but you dont force it so that you can maintain the friendship. Even as you hold the expectation for others on your team. This will erode the trust you are building with others on the team.

Its such a hard balance to strike because in a way you are not in control of it. Relationships build themselves through shared hardship and mission. But its always important to check yourself and make sure you are still able lead the people you have a close relationship with.

Able to execute extreme ownership when exercising decentralized command

One of the hardest things is to release control. It is hard to give people complete autonomy. But that is what you need to strive for. We know that in computing decentralized systems are more resilient and yet when it comes to human structures we hold onto centralization. You need to find ways to allow your people autonomy.

The catch is that even though your teams are more autonomous, you are still the one who are accountable for their actions. When things go wrong it is your fault. And when things go wrong, the temptation is to give up on decentralization and pull everything back to centralized command and control. The balance is to let your teams operate while making sure they are following your commander’s intent.

This is an extremely difficult balance to achieve.

Conclusion

I wrote this post for myself as much as for others. Each essay on an individual dichotomy was a reminder to stay balanced. If you take leadership seriously, I highly recommend writing your own dichotomy series. Put your thoughts down on how to stay balanced. Reread your message to yourself regularly.

Finding the balance is not a single event. Its a constant set of micro-adjustments. There are times when you are in balance and some where you have fallen out of balance. Writing yourself a memo will help you to objectively view yourself and find the areas you are most likely to go off kilter.

Last week, I discussed my perspective on the history of software development. As programming the software became decoupled from building the hardware, software engineering, also known as programming, split from engineering. Because it exists in the digital world, there is a different set of rules. Once the split occurred, software processes adapted to the rapidly changing landscape of the digital world.

Not only did the process of writing software change, but the people who were writing it also changed.

Art or Science

Software is as much an art as it is a science. I believe this is partly due to the lack of constraints in the digital world. In the physical world, you wouldn't build three slightly different bridges just to test a hypothesis. However, this and more are common in the digital world.

There are hundreds of languages, patterns within those languages, and frameworks within those patterns. With so many options and no significant constraining factors, like gravity, developers are left with only a few constraints.

Even the way a developer writes the code and names the variables has a sort of art to it. Good programming reads like a well-written article or even a poem. It has names that immediately convey an understanding of the data within and the flow of that data through the process. Bad programming, like bad art, immediately grates on the nerves.

But bad programming can still work. It could even compile to the same underlying assembly. It's just bad for the humans who need to interact with it.

So while it may seem like software development is an art, consider that teams with a lack of engineering processes tend to do poorly. There is a lot of discipline required to create good software. There are also known patterns and anti-patterns which require programmers to read and stay up-to-date on their craft.

Deploying quality software in a timely manner requires a good engineering culture. One of open criticism of the code and a clear process for how the software moves from idea to delivered solution. As the complexity of the solution grows, so does the need to take a very measured and consistent process to change it.

The answer, as you may have deduced and in my own opinion, exists somewhere in the middle. It is both an art and a science. Tilting in one direction or the other has trade-offs.

Software Developer or Engineer

TThe debate over whether we should call these people developers or engineers has existed for a long time. Like the debate over whether software development is an art or a science, it's not a clear answer with a clear winner.

I lean towards the title of software developer, but even at my own company, our official titles are engineering titles. My conclusion is that once there was the break from the physical world and software became its own thing, we had a flood of people writing software without formal training.

This is not a knock on people without formal training. I am one of them. While I have a degree, it's not in computer science. The physical world requires a credentialed person to engage in activities that would be impactful to other humans. You don't want a bunch of self-taught engineers building your bridge.

I'm sure in software there are still places that the level of engineering and education has to be extremely high for those writing software. Things like nuclear power plants, medical devices, and missile defense systems. But for 99% of the business software in the world, having someone who learned through their own curiosity and self-discipline is just fine. These people have gone on to run multi-billion dollar companies.

Once that crack opened up, people began to flood into the industry through bootcamps and late-night self-taught programming sessions. I think the gate should be wide open. However, a 3-month bootcamp isn't like a 4-year engineering degree, but it doesn't have to be to get people started in the industry.

With good mentorship, people can become quite qualified for the job in a year or two. I think colleges should acknowledge that software development doesn't have to be computer science and carve a new path for students that is heavy on the software but light on the engineering.

The Motley Crew

This was supposed to be a one-part article about how to manage software developers, but it has grown to three parts. Part of the difficulty in managing software developers is due to the nature of the job being a mixture of art and science. This attracts a wide range of people with different skillsets, thinking and training.

But all of that is due to the fact that it's a job that exists in a different world. Add remote work, and we are talking about a truly digital workforce working in a digital world. Next week, I will finally get to some conclusions about how to lead people and teams in this new world.

If you liked this, consider subscribing to my Substack. I publish an article about software engineering and software engineering management every Tuesday. If you want even more, consider joining my paid content where I am writing a course in real time about making the jump from developer to manager.

Subscribe now

For the last 6 months I have been writing about how to become a development manager for my few paid subscribers. My intention was to write a course on being a good development manager and have a short section on how to move from individual contributor to management at the beginning.

I wrote and wrote and kept writing. It seemed like there was lots to cov…

Read more

The software development world is wild. I would argue that no other industry is quite like it. Its half art half science. Some people go to school for it, some don’t. Some people get it and are on a completely different level, and some people struggle through and just make a living off of it. I have a theory on why all of this is. To explain it, I have to go through the history of software development as I see it.

The Early Days

Computer Science used to be just that, a science. Way back in the day you had to understand the physical makeup of the computer to be able to program it. Scientists were working with resistors and gates and all kinds of things that I only have a basic understanding of, because I am not a computer scientist.

But it was a practical science, not a theoretical science to the people who participated in it were called engineers. They used engineering principles since they were dealing with the physical world.

Think of how physical structures are made. An architect designs the whole thing. Engineers are involved in modeling and stress testing the models according to their specialty and then when it moves into the build phase manual workers build the structure according to the specification.

Because the software was so dependent on the hardware, software engineering was a physical science.

Software as Engineering

As computers advanced, engineers were able to build more complex applications. The coupling between the physical computer and the software running on it was loosening.

Even as there became less need to understand the physical structure of the computer, software engineers still applied processes from the physical engineering world to act of building software. This is evident from the major development lifecycle created for software, waterfall.

Waterfall mimics the processes of creating physical things. Architects designed it and engineers planned it and built it. Software development was more like manual labor. By the time the code was written they were just implementing designs and specs that we already determined, committed to and meticulously specified.

People kept building software like they were building bridges. There was long planning processes to make sure everything was thought of and all aspects were considered. The specifications were detailed and left nothing to interpretation. Only then would work begin on the project.

But something happened. As languages evolved and became higher level the coupling between the hardware and software that had been loosened finally broke.

The problem was that engineers were building in a digital landscape not a physical one. And by the time the thing was built the landscape had changed. Imagine building a bridge over a river and by the time you are done the river was twice the size and a mile away!

We needed to leave the rules of physical engineering behind because we were in a new world. A world that needed a new set of principals. A world that needed a new kind of worker.

We needed to build things but also adapt to the way things were changing. Enter Agile.

The Magical Digital World

The digital world is like a magical kingdom. And once people started to understand this the rules and the tools changed.

Lets go back to the bridge example. Imagine if you wanted to test something about a bridge so you built two of them, or a hundred of them. Maybe you wanted to test if people enjoyed one bridge more than another.

None of that is feasible in physical world. There is a small bridge that goes over a creek near my brothers house. Its currently being replaced. It is a simple bridge but it will take 6 months to replace.

The digital world doesnt have the same rules as the physical one. We can simulate everything on the real infrastructure of it or exact replicas. For example we can simulate traffic, infrastructure outages (chaos). We can swap out the infrastructure with new infrastructure daily or even multiple times a day.

Imagine doing that with a bridge.

At some point we realized that the physical rules didnt apply. We were building using engineering processes designed for the physical world but we were in the magical digital world. It was inevitable that our processes would change.

Agile

If you follow the history, the realization that we were “not in Kansas anymore” wasnt like flipping a switch. People began to realize it slowly. There were frameworks like Kent Becks Extreme Programming or James Martins Rapid application development. I am sure there were lots of others. These were people who didnt accept “the way we always did it” and began to see a new path forward in the digital world.

If there was a switch to point to it would be the Snowbird Utah meeting where a lot of these people got together and came up with the Agile Manifesto. I wont go into the almost Arthurian tale that has spun up around that meeting. It was important, the people were smart and yes it changed the was we think about software.

Agile took the architect, engineering and code writing process and shortened them to small iterations. In order to build in this new landscape we needed to be able to change the design quickly. This took the 6-12 month timelines of software projects and broke them up into 2 week increments. This meant that the phases couldnt be separated and the people didnt need to specialize on a certain phase. The same people could architect the solution, test it and build it.

The software was built incrementally so that it could adapt to feedback and to the changing landscape. And the landscape was changing fast. Projects could no longer take 2 years because the world they were released into would look nothing like the one that existed when the project started. This feedback loop meant that the world began to change even faster.

Naturally people’s tolerance for error went up. Without laying out the design completely ahead of time keeping everything synced up was difficult. But developers began to realize in most cases the consequences of errors in the system were not as they were in the physical world. If you built a bridge that didnt connect in the digital world cars didnt go careening off it.

The Present Age

That brings us up to present time. People have fully embraced this new digital world of software development. With the advent of the cloud it took things to a whole new level. Software was completely untethered from the physical world and now not only could the software be created in this magical realm but so could the physical components needed to run it. Working software could be delivered in weeks or days.

This has lead to more pressure on the timelines. Everyone is moving fast and the only way to win is to move even faster. With the new AI models entering the development world and the general population it is getting even crazier. Writing software isnt just untethered from the physical world its now disconnected from the logical one as well. You cant look at the model and see the flow of logic through the software. Its truly magic.

Part 2

This post was originally about how to manage software developers. As I worked on the title I was trying to decide if I should call it “How to Manage Software Engineers” or “How to Manage Software Developers”. I went to look up the difference and the results were mostly about the definitions of the word “developer” and “engineer” and the conclusions varied wildly.

I also didn’t see anyone talking about how the history of the trade had changed drastically from the time when engineering principles and understanding resistors and gates were required to the time of feeding data you pulled off the internet into an LLM.

Some describe writing code as a science, some describe it as an art.

I wanted to understand who the people were who were writing the code and how to manage them. In order to do that I felt it was important to set the stage for how this eclectic group was assembled. We have PhDs down to self taught enthusiasts in all levels. Just like the rules broke in the digital world, they also broke for who could succeed in the physical world.

In part 2 I will try to break down who the people are in this magical world of software development and how to manage them.

“Don’t half ass two things, whole ass one thing” - Ron Swanson

Twice in my career I have found myself in the in-between phase and both time the venerable words of Ron Swanson came to mind. Its hard to bridge two jobs. I don’t think it can be done well. If you are being asked to manage and also be a major contributor, one or both of those will suffer. If …

Read more

It's a new world in IT. With massive layoffs happening, you could be excelling at your job and still find yourself out on the job market. You need to start preparing for your next opportunity now. It is taking people multiple months to find jobs, and they are competing with hundreds of others in the same position. You will need something to stand out, and now is the time to start working on it.

I wrote about the need to chaos engineer your life in an earlier article. It's about assuming the worst situation and making sure you are prepared.

Let's run the simulation now:

You just got laid off.

• What are you going to do next?

• Who are you going to talk to?

• What will you need to "freshen up"?

• What will you do to stand out?

• What is your interview plan?

All of these things can be answered today. You don't even need to start interviewing and actively job searching, but that may be a good option if you feel like you are in a situation where layoffs are likely.

The Basics

There are a few things you can do to make sure you have the basics covered:

• Keep your CV up-to-date quarterly. As you finish goals, add them to your LinkedIn profile.

• Keep an eye on job opportunities. Which companies are hiring? Do you know people who work there? Stay in contact with them so that if you need their help, you already have a good relationship.

• Look at the skills and qualifications mentioned in job descriptions and make sure you are building that experience.

Interview

This can be time-consuming, so I would recommend it only if you feel that your risk of a layoff is high but you are happy at your current job.

• Go through the interview process if you can secure an interview.

• If you can't get an interview, you need to figure out why. It's better to know now than when you are out of a job.

• If you get the interview, use it as an opportunity to practice. Figure out what the company is looking for and anticipate the questions you will be asked.

• Use this experience to improve your current job. Build the skills and experience that the job market is seeking and make sure you have answers to common interview questions.

Advanced

This substack is part of my advanced strategy. I am laying the groundwork in case I need to stand out. I will have months and hopefully years of writing about my own philosophy and methodology when it comes to leadership and management. I will have built connections through the act of putting myself out there repeatedly.

Find your own niche. Build a community. Imagine if you could be known as the "angular component guy" and someone needs a frontend developer. Your name might even be recognized by the team who is interviewing you. There are lots of small niches, areas of technology that can have a public champion. Find those and create content. It might take a few months, but you don't want to be trying to create content while you are actively job hunting. You want to leverage it while you are on the hunt.

Good luck to all of those out there looking for jobs. I know it is hard. If you have a job, now is the time to think about your next opportunity, even if you are happy and committed to your current one. To do otherwise would create a vulnerability that Murphy will exploit.

If you liked this, consider subscribing to my Substack. I publish an article about software engineering and software engineering management every Tuesday. If you want even more, consider joining my paid content where I am writing a course in real time about making the jump from developer to manager.

Subscribe now

We think that business runs off of processes and procedures but in reality those both take the back seat to relationships and stories. As a developer who is looking to get into management you will need to work on building relationships.

Your goal should be to build relationships with everyone but you only have so much time. If you have to choose, there a…

Read more

It is known in physics that you can't observe something without changing it. Even in software development, the trickiest bugs are the ones like race conditions that change when you pull up the debugger.

As a manager, you also change things by observing them. You carry power just in your presence, and you need to be aware of it. I'm not talking about the abuse of power; I assume you are already onboard with the fact that it is a bad thing. I am just talking about your role and how others will respond to your questions and even your presence.

I learned this from the most unlikely source.

I would like to say that I was given this advice by one of my mentors, but the truth is that this advice was given to me by one of my most difficult employees. I am sure that at the time he was trying to find a way to cut me down, but the critique was true.

There is a sub lesson here.

You should be able to take criticism from anybody. Just because someone does not have your best interest in mind doesn't mean their feedback will be wrong. It doesn't mean it will be right either. This person even tried to get me fired, but I still remember this particular conversation and the lesson I pulled out of it.

Take the criticism and consider it objectively.

Back to the topic of power and knowing how your presence will affect something. I remember the first time I didn't go to a meeting. I was invited, but I didn't show up. I don't remember what the meeting was about, but I remember that my presence as the manager would influence the outcome.

I had delegated the task to someone on the team, and they had set up a working session and invited me. I thought, "Great, I can check in and watch how they are going about this." As the meeting time got closer, I began to realize that my presence would disrupt this leader's ability to run the meeting.

This leader would have an easy solution to defer the hard questions to me. I wouldn't be "just an observer," I would be dragged in as a participant. Even if I wasn't dragged into the conversation, my presence might change the it. It might force people to be a little more reserved in their criticism or a little more vocal in areas they thought I cared about. Whatever it was going to be, I needed to not be there to let the leader lead.

As new leaders we think that we need to be everywhere. We want people to know we support them so we keep showing up and offering that support. We go to every meeting and every working session. But our presence is causing other effects, some good, some bad. We need to understand these. We need to know our power so that when we show up we know how it will change to environment.

Sometimes the best leadership choice is to step back, decline the invite, grab a cup of coffee, and let others run the show.

I am notorious for screwing up my travel. I have screwed up more times than my pride will allow me to quantify.

I remember one time when we happened to actually get to the airport early. We were so glad that we did because there was a huge line to check bags. We stood in line forever. Right before we were at the front of the line we were informed that we were actually IN THE WRONG LINE.

I was pissed, it was confusing the way the airline had set things up and it appeared that we needed to be in that line when in reality we could have just gone straight to the bag drop kiosks.

I am very familiar with airports and airline procedure but when things are unclear it is hard to navigate familiar territory.

What's my point?

You are likely going to have very competent people joining your team. They may have been in product organizations and the functions inside of a product organization will be very familiar to them. However, every company is different and making sure that your new team members are getting up to speed fast is your responsibility. You don’t want them stuck in the wrong line when you can quickly point them in the right direction

The Basics

Every company will have different requirements for what a person needs to do to be onboarded fully. As a development manager you need to have a framework for how you are going to be getting people up to speed on your team. Your company may have a process to onboard people and your product team may have a process as well.

Here is the basics for your process:

• Share the vision for your company and your team. Start with why!

• Schedule out the 30, 60, 90 day touch points.

• Make sure they have access to all necessary systems. For example, they need to be able to create a support ticket to internal IT.

• They need to understand how to log work and hours if they are tracked.

• Walk them through architecture and internal documentation.

• Have them clone, build, debug and test core applications the team is working on

Add to this list anything that is particular to your company.

Dont feel like you need to do this all yourself. I create a quick matrix and assign team members the task of training the new guy on different items. Have the new employee record the sessions and they will have a reference for their first few weeks on the job.

The Algorithm

The basics are table stakes and can be done in the first few days. It gets them into the organization and arms them with the tools they need to succeed. But they are far from being onboarded. They need the institutional knowledge. The information that exists only in peoples heads. This can take a long time and be tricky to do. However, I recently read a post by Ryan Peterman on how to onboard that had some advice on how to speed it up.

Peterman has a lot of good advice so give it a read but in particular he referenced a process created by Boz, the CTO at Meta. This is easy to remember and easy to do.

The first step is to find someone on the team and ask for 30 minutes with them. In that meeting you have a simple agenda:

• For the first 25 minutes: ask them to tell you everything they think you should know. Take copious notes. Only stop them to ask about things you don’t understand. Always stop them to ask about things you don’t understand.

• For the next 3 minutes: ask about the biggest challenges the team has right now.

• In the final 2 minutes: ask who else you should talk to. Write down every name they give you.

Repeat the above process for every name you’re given. Don’t stop until there are no new names.

I like things that are simple. The amount of complexity we deal with on a regular basis can be overwhelming, especially if you are joining a new company. This process gives a clear start and stop point and it gives a natural reason to approach people.

Give this process to your new hires and see what they do with it.

Improve

If you did the basics and scheduled out the 30/60/90 day meetings once your new employee has joined you should check in on the process. Most interesting is to see how their opinions and understanding evolves over the first 3 months. Take note of this. You will hopefully get to see your own team and organization through the eyes of the outside.

• What is the first impressions?

• What perceptions are confirmed?

• What perceptions were not real?

• What things were hard to uncover but really important?

People rarely take advantage of this time. It is fleeting. Once your new employee hits 90 days they are integrated and you no longer will have the new eyes and new impressions to reflect back the parts of your organization that you cant see.

If you liked this, consider subscribing to my Substack. I publish an article about software engineering and software engineering management every Tuesday. If you want even more, consider joining my paid content where I am writing a course in real time about making the jump from developer to manager.

Subscribe now

A few years back I gave the thumbs up to hire a promising new developer. He was hired in at an entry role with the idea that he would quickly get promoted due to his prior experience.

He was working out great and I was feeling pretty good about my decision to hire him.

He quickly started making a scene about getting the Sr position. Usually we don't promote that quickly but since we had talked about it when he had started and he was working out well we decided to promote him out of band. He had ruffled a few feathers but he got what he wanted.

I thought we were done and ready to get back to work.

Soon after his promotion he started demanding a principal role. The ruffled feathers were starting to catch fire. He ran his request all the way up to the top, to the CEO himself. It was an incredible example of self destruction. I am not sure what his plan would have been had he been given the role when he burned every bridge trying to get there.

He was let go, or rather he “quit”. The feeling that we needed to part ways was mutual.

Ego burns bridges.

There is almost no strategic value in burning a bridge. It may feel good at the time but it will only create a scenario where you have less options to work with in the future not more. Be clear about what you want, even be willing to quit if you feel that passionately about it but it doesn’t make sense to destroy future potential by creating hostile relationships with the people you disagree with.

Each job you work, or person you work with becomes a vector for future opportunities. Maybe when the job market is booming you can afford to set your current job on fire but once times get tough and getting a job requires someone to bump your resume to the front of the line, you will be glad that you kept your ego in check.

I love learning.

It is literally my job to learn things and I do well at my job. However, there is an insidious trap waiting for us as knowledge workers and we rarely see it.

Recently I decided to take a break from one of my favorite activities, listening to podcasts. Its all part of a new plan to avoid the trap and to make progress in my life.

Lets start at the beginning.

I grew up in a school where being smart was looked down upon. "Book learning" wasn't much use if you couldn't use it to build a fence or ride a horse. I still had friends, but it was clear that they valued learning that manifested itself in physical work over the mental and digital world.

Their lives took them into heavy machinery operation and pipelines, mine went into software. I still go back and visit, hang and joke with them. We all made the right choices and we still give each other crap about those choices. 😁

However, there is a problem with knowledge work that my friends were able to see in middle and high school that has taken me years to see. They couldn't articulate it at the time but their simple heuristic that knowledge had to manifest itself in the physical world solved for it.

The problem is this:

The pursuit of knowledge for the sake of knowledge is unbounded.

There is no natural filter to our learning, if some knowledge is good, more knowledge is better.

If one book on management is good, then 5 is better. We read, read, read and listen, listen listen. Trying to stay ahead of the game and build a base of knowledge to hedge against the future.

I remember a twitter bro who wrote a whole thread about how to read 100 books in a year. I asked why not read one book and apply it. He hadn’t considered that. The idea of applying the knowledge wasn’t built into the program, it was just about having it. I think he assumed that the application was the easy part, that it would just happen if he knew enough.

Knowledge workers like him can get into a state where they stop asking why. If its information, they should know it. So they soldier on and develop an addiction to learning and information. Yet, the amount of information available is ballooning out of control and our ability to retain information is diminishing. With so much available we can learn for 1000 years without ever applying a single idea.

The physical world works in the inverse. Application has to be first. You do to learn. That’s why my friends were so frustrated sitting in desks learning from books, it was the inverse of how people actually learn in the physical world and their filter caught it immediately. They laughed and joked about this inverse of the natural world and they poked fun at the people like me who embraced it.

Who was right? Is it better to do first or should we constantly be filling up our minds with information?

The answer, as is the case 99% of the time, is somewhere in the middle. Watching 1000 hours of wilderness survival videos wont make you a much better survivor if you never spend a night outside. But if you are in the wilderness and struggling to survive, you can gain some valuable insight from other people that might keep you alive.

The pursuit of knowledge being unbounded is the first issue, but its not the insidious trap. The trap is so much sneakier.

The pursuit of knowledge becomes a coping mechanism to distract us from our real problems.

Very few people want to face their own issues and work through them. We all have problems and we don’t want to face some of those problems, let alone start solving them. So we drown out our mind with learning.

Doing the dishes, podcast.

Driving in the car, podcast.

Sitting on the toilet, Youtube.

We trick ourselves into thinking that we are redeeming the time and in a way we are. But if we don’t ever turn off the firehose of information and deal with what we have got, we are not going to make progress on the real issues. We will feel good because we will be learning so much, but we wont see change because we dont take the time to execute on the things we are learning.

We avoid the areas of our life that we need to focus on by cranking up the knowledge. We stream 1000s of the best ideas into our heads and think there is no way we will fail if we have the best ideas.

But we are disconnected from the physical world. We have forgotten that you have to “do” to learn. Sure some ideas lay dormant and come back to life on occasion but the return on investment is low.

Which brings me to my decision to shut the hose off and delete my podcast app. I realized that I had replaced my own thoughts with the thoughts of other people. I was sacrificing observation, reflection and reinforcement of what I had already learned for information and ideas. It seemed entirely possible that while I was learning more, I was actually getting worse. I was getting rusty at the very basics that I spend my time writing about.

So I shut off the outside. Not permanently. I still have audio books. There is still also a time for learning. But I am starting with action, observation, reflection and the deep internal work. Then I am moving to learning.

I’m early in the experiment. Time will tell.

If you liked this, consider subscribing to my Substack. I publish an article about software engineering and software engineering management every Tuesday. If you want even more, consider joining my paid content where I am writing a course in real time about making the jump from developer to manager.

Subscribe now

Today I am going to take a little detour from my usual topics of engineering and leadership to talk about you and me. Maybe its not too much of a detour because ultimately leadership starts with us, will we show up today and more importantly will we show up every day and do the hard work.

Join me as I meander through computer engineering, the endurance athlete mindset, and neuroscience and pull them into a challenge for the year.

Chaos Engineering

I remember the first time I heard about Netflix’s Chaos Monkey. Netflix streaming had just launched recently and the Netflix engineering blog was putting out a lot of unique content at the time. I’m sure chaos engineering had been lurking around but Netflix brought it into the mainstream. Here is how they described it in their early post:

“One of the first systems our engineers built in AWS is called the Chaos Monkey. The Chaos Monkey’s job is to randomly kill instances and services within our architecture. If we aren’t constantly testing our ability to succeed despite failure, then it isn’t likely to work when it matters most — in the event of an unexpected outage.”

Chaos Monkey was just what it sounds like. It was a piece of software that would do random things like turn off a server, mess with configuration or increase the latency. This kind of chaos caused a lot of issues at first but over time it allowed Netflix to build extreme resiliency into the system.

Rather than wait for disaster to strike they found a way to simulate disaster so that they could be confident that their software would work even if everything seemed to be going wrong. If an actual outage happened in the cloud it was just another regular day for Netflix.

I have always been intrigued by chaos engineering. It was a level of crazy that had some logic to it. It was a place that few wanted to go but the ones that did considered it worth it. Nobody wants to have outages or failures but Netflix decided that the only way to avoid them is to have them every day.

I had only heard about chaos engineering in the context of software. But should it apply to just software?

Chaos for Humans

What about you? What about me? Are there other uses for the concepts of chaos?

I began to think about stress and how most people are one stressful event away from disaster. They only have a little margin for error in their lives and like software, every day has the potential to cause massive failure be it physical, mental, emotional or spiritual.

Is there a way to do something about that? Is there a way to chaos engineer ourselves?

I started building a philosophy around this concept. I called it Forged Humans and it became the seed idea eventually for Forged Managers. Forged Humans was about embracing stress to make you stronger. Human systems have an antifragile nature to them. Meaning the more stress you put on them the more resilient they get. I began to deep dive on stress and its effects across 4 domains: physical, mental, emotional and spiritual.

I can tell you for certain that the philosophy of embracing stress works. The problem is that the philosophy sucks. Literally. It is hard to always be pressure testing yourself. So I have fumbled my way through life trying to embrace stress more but in my weakness resorting back to comfort.

An Unusual Conversation

I hadn’t thought real deeply about the philosophy of stress recently but I picked the topic back up after listening to a podcast between Andrew Huberman and David Goggins. This conversation hit me right when my mind was ready for a new idea.

David Goggins has taken the concepts in Forged Humans farther than anyone I have heard of. His philosophy is “embrace the suck” and “stay hard”. His story is rough ad full of pain but he has embraced it. Because of that he has done a lot of interesting things in his life and he has a deep understanding of himself.

Huberman is a neuroscientist who through his podcasts has also laid out a lot of the same things I had been thinking related to stress and the benefits of stress that most people don’t get. He provided a lot of the scientific evidence that backed the realizations I had already been making.

Their conversation is a hard listen if you are not used to Goggins or strong language. However, if you are able to decipher it Goggins lays out his simple yet extremely difficult philosophy.

“Do things you hate”

Not things you hate from a more standpoint but things that are good for you but you hate to do. Goggins is a renown ultrarunner but it turns out, he hates running. Every day he gets up and does it. He chooses to do the thing he hates most and he credits that thing to his strong mind and his ability to endure.

It turns out that there is scientific backing for his philosophy. A part of the brain called the anterior midcingulate cortex appears to be responsible for willpower and as we do something we don’t want to do it grows. The bigger it grows the more willpower we have for other areas of life.

Huberman points out the following:

“When people do something they don't want to do, like add three hours of exercise per week or resist eating something while dieting, this brain area grows."

Have you ever noticed that after working out it is easier to say no to the donut. I always attributed that to logic. I didn’t want to undo what I had just worked hard for. There is some logic there but perhaps there are other, more deeply built in, systems at work in these decisions. Maybe my midcingulate cortex just grew a tiny bit.

The Curse of Abundance

Why put yourself through “the suck” and start to chaos engineer yourself? Do you really need to increase your willpower by increasing your midcingulate cortext? Naval, another great thinker on these topics introduced me to the curse of abundance. It goes like this:

"Most of modern life, all our diseases, are diseases of abundance, not diseases of scarcity… In an age of abundance, pursuing pleasure for its own sake creates addiction.

The modern struggle is really about individuals—disconnected from their tribe, religion and cultural networks—who are trying to stand up to all these addictions that have been weaponized: alcohol, drugs, pornography, processed foods, news media, Internet, social media and video games.

We live in unprecedented times. People are no longer constrained by access. Every addiction is available 24/7 for almost no cost. The job market is tough and our communities are fractured. To put it another way, you don’t have a choice. That is the paradox of life, hard times will find you, do you want to be ready for them when they do?

A Call to Action

2024 has to be about action.

The world is full of self help books and full of broken people. The idea is that reading the book will somehow help with your problems. But reading a book wont tell you where you are going to break, it wont build your willpower.

In the same vein, Chaos engineering isn’t about reading architecture or data flow diagrams to find issues. It assumes that you cant learn the weaknesses of the system that way. You have to do the action. You have to stress the system to see where it breaks.

We cant improve through learning alone. We have to do the things that we don’t want to do to find the insights we need to improve.

If you liked this, consider subscribing to my Substack. I publish an article about software engineering and software engineering management every Tuesday. If you want even more, consider joining my paid content where I am writing a course in real time about making the jump from developer to manager.

Subscribe now

The humans at your company are the greatest asset your company has. Software exists for people and it is built by people. So many developers, myself included, come into the profession because we are good at one thing, avoiding people. Unfortunately avoiding people doesn’t work when you get into leadership, because leadership is about people.

One of the latest buzz words to come out of the psychology world is "Emotional Intelligence". I will admit that I have to work at emotional intelligence. It does not come naturally. However, I have two people in particular who I know are naturals. My wife, and my friend Christian. Here is how I know:

At my work we had to take a personality test. Each personality type was represented by a color: Blue, Green, Red and Yellow. No person was completely one color but they had a primary color and then a ranking of the other colors. I went home after work and giving her as much information as I have just given here asked her to tell me my 4 colors. She got them 100% correct. She didn’t even need to know what the colors meant. Now you may say that is luck. So a year later I asked her again. I had forgotten the colors myself and even guessed my own wrong. But again she named them off. She knows people, she can read a room. It just is easy for her.

Another friend of mine succeeds at business where ever he goes and when he shows up he is the life of the party. I called him one night and he had just finished watching a rom com. I would never watch a rom com by myself so I asked him what the heck he was doing. He confessed that he liked to study people and that movies like this were just that, and exposition on human interaction. That is when it clicked. He is successful because he gets people and knows how to make it work for him.

This brings me to one of the most valuable soft skills you can develop as a leader is tactical empathy. This concept comes from Chris Voss in his book, "Never Split the Difference". Tactical empathy is simply understanding the other person. You don't have to agree, you just have to understand. I have found this super helpful to think about with respect to your boss.

If I can understand your boss and what they need, then it is easy for you to provide it and make their life extremely easy. It is also important as a boss. You just came from the developer role, don't forget what it is like to be in their shoes. And if you can put yourself in their shoes, you will see how your leadership is impacting them.

You will find that people are not as complicated as you think. You just need to actually study them. Learn what motivates people and what doesn’t. Get in their heads and see what makes them tick. If you want to go into leadership this is going to have to be something you get comfortable with.

If you liked this, consider subscribing to my Substack. I publish an article about software engineering and software engineering management every Tuesday. If you want even more, consider joining my paid content where I am writing a course in real time about making the jump from developer to manager.

Subscribe now

Delegation is a very important skill as a manager. But the goal of this course is to build management skills before you become a manager. It’s hard to develop this particular skill if you dont have anyone to delegate to so it calls for a little creativity.

Much of leadership is packaging up ideas in a way that other people can work on them. There are two…

Read more

For thousands of years, people relied on oral tradition and stories as a mechanism for maintaining culture. People would pass down the stories from generation to generation. The good stories kept getting told, and eventually, these stories became the foundation for the formation of a unique identity and culture among the people who shared them.

In business, on the other hand, it’s important to focus on procedures and reducing tribal knowledge. Oral tradition is not a great way to scale your team reliably. It makes business sense to be able to grow the team rapidly or to swap people out of the system and have the system keep going. If your entire company relies on certain people being there or passing on knowledge, it creates a lot of risk for the business as things scale up and down.

Some might argue that it's possible to pass down culture in the same way we pass on knowledge. Write down the culture and have people read it. However, culture is embodied by the practitioners, it's observed, not read. If the words on the page don't match the actions of the individuals, they are meaningless.

It would appear then that these two things are at odds with one another. On one hand, we should reduce dependencies on oral tradition and individual stories to reduce the risk, but on the other hand, the shared identity and actions of the people create the culture that is vital for a company to thrive.

What then? Does creating systems go against thousands of years of human tradition when it comes to culture? Are the two mutually exclusive?

The answer, like most right answers, is that the truth lies somewhere in the middle. It's important to build systems that keep the engine going, but that should not be at the exclusion of stories and cultural narratives that hold the team together.

That begs another question. Is culture only organic, or is it something that can be built?

Once again, the answer is both. Culture is built both from the bottom up and from the top down. It's both set and discovered.

This all sets the stage for a topic I think is vital to leadership. I have seen the best leaders do this on instinct, but I have only seen a few consciously set this up. The topic is obviously about building a culture, but the "how" is via heuristics.

What are Heuristics?

Heuristics are short phrases that encapsulate a large idea and, more importantly, evoke many shared memories. My mind immediately went to Arrested Development and their phrase, "That's why you always leave a note". On a more serious note, some business ones are "Run to the fire" or "Inspect what you expect," or one of my favorites: "fix it twice".

The reason they are so powerful is that they encompass all the stories and lessons behind them. The more you use them, the more meaningful they become as more and more stories contribute to the phrase. Once the phrase is established, you simply use it instead of giving the long, rambling instructions that you used to have to do.

These phrases are passed on to new team members, and when they inquire about them, the best stories are retold. Even though they weren't present for those stories, they begin to share in the team's cultural heritage.

Heuristics From the Top Down

Culture can be driven via heuristics from the top down. It takes a lot of repetition, but it can be done. For example, I have seen a leader in support use the phrase "run to the fire" to talk about the need for people to drop what they are doing to make sure a customer is being taken care of.

This was a planned heuristic. He saw a need for people in his organization to rally around the customer and help them when things were going wrong. He implemented this and would bring it up often. Sometimes as a reminder, but often as praise.

I use "fix it twice" in software development. I learned this from my first mentor when I was a junior developer. This means to quickly resolve the customer's issue, sometimes through a workaround or a quick code change. Once the customer is stable, the job is only halfway done. You need to fix it again to prevent it from happening in the future. This often involves a larger code change and some form of regression testing.

So it is possible to assess the team, identify their needs, and develop a plan to implement a heuristic that fills a specific gap. Alternatively, you can adopt heuristics from previous teams you have managed. However, they may not initially have the same cultural impact. You will need to share stories from your previous team or explain the lessons behind the phrase to get it started.

I have observed that heuristics initiated in this way take a lot of time to gain momentum and need to be reinforced more frequently by the leader. Nevertheless, they are still a valuable tool and are probably more common than heuristics that originate from the bottom up.

Heuristics From the Bottom Up

Bottom up heuristics naturally emerge from interactions within the team. However, it still takes a conscious effort by the leader to recognize and adopt them as team heuristics.

I believe it is important to be observant of stories that exemplify the positive attitudes and behaviors within the team, especially the stories that are frequently retold.

Once the stories have been shared, they can be condensed into heuristics. Heuristics serve as shorthand, allowing you to convey the essence of the story without having to retell it.

For instance, there was a time when we were working on a graph API that would serve as the main integration point for our entire product. I was concerned that other teams might not fully grasp the significance of this project.

We had made progress and had critical data in the graph. When people asked, "How can we access this data?" I would respond, "It's in the graph." I repeated this phrase so often in one meeting that people started teasing me. They would say "It's in the graph" for everything, and the phrase stuck. It also solidified the graph as the integration point for the entire product. To this day, it is still jokingly repeated.

Another example occurred when we were rapidly building a product, simultaneously working on the backend and frontend. I wanted to emphasize the importance of communication to ensure alignment, so that when both sides were completed, the integration would be seamless.

I used the analogy of building a bridge from both ends and expecting it to meet in the middle. I used hand gestures to indicate alignment or misalignment between the two sides of the bridge. People caught on to this and soon started using it as well. We reached a point where we didn't even need to mention bridges; the hand motion alone conveyed the importance of communication for alignment.

Bottom up heuristics are more likely to stick because they come from the people who are meant to use them. However, you need to be vigilant in identifying them and amplifying the ones that you ultimately want to succeed.

Conclusion

Having a good, shared culture is vital for a team. Knowing this, be on the lookout for phrases that embody the culture and amplify them. If you need to address an issue, don't forget the importance of having a plan for how to communicate all the lessons in a simple way. This way, you won't have to spend 30 minutes at each staff meeting reinforcing the message. Instead, a simple hand motion could convey the thousands of words you would have said and be clear to your audience.

Lessons Learned from a Macerator Mishap 💩

I was freakin pissed. I was staring at my macerator (a poop grinder of sorts) on my RV. I was emptying my sewage tank and the macerator was grinding things up and sending the goods 200 feet away to the septic tank, like a champ. But right now the macerator wasn't working at all.

Something had gummed it up and it was dead.

I had imagined this scenario before but had always put it off. After all I had been doing this for months and had not had a problem (ok, one or two close calls). Everything is good until its not.

There is a special part that can go with the macerator that has a gate on it. So if it fails you can cut off the flow of juicy goodness and fix the issue. I just hadn't gotten around to getting it, because I was lazy and everything had been working. Again, everything is good until its not.

The only remedy was to remove the macerator and deal with the flood of shyte that was about to gush forth.

Needless to say I took a long shower that night.

What is the moral of this gruesome tail? What I failed to do is to plan to fail.

As a development manager you will fail.

Your product will fail.

Your team will fail.

But the worst kinds of failures are the ones that you knew what to do. You just waited, not wanting to put the time in to something that would only be needed if the shit hit the fan. I can tell you from experience that in the middle of those experiences you will dream of going back in time and making the small change that would have protected you.

So go right now, fix that little thing that you know you need to fix. Your future self will thank you.

Oh and your team also has these areas that they know about too. Get them talking. Do a premordem and figure out if something went wrong what the cause would have been. Because things will fail and as a manager you are ultimately responsible.

If you liked this, consider subscribing to my Substack. I publish an article about software engineering and software engineering management every Tuesday. If you want even more, consider joining my paid content where I am writing a course in real time about making the jump from developer to manager.

Subscribe now

People need to be able to see themselves from the outside. They may think they are doing amazing, but others are perceiving them as an ogre who walks around and smashes things. Managers need to be able to give tough feedback. They need to set the expectations and let the people they manage know when they are not meeting those expectations.

While it's important to give feedback, this is about how to receive feedback. Creating environments where you can get people to be honest is a skill. You need to working on getting feedback about everything.

Feedback should be your drug.

Now, that doesn't mean all feedback is good. But the fact that you got the person to give you feedback is a win. You can always filter the feedback later. But it's a win that you were able to get it in the first place.

Remember: when people tell you something’s wrong or doesn’t work for them, they are almost always right. When they tell you exactly what they think is wrong and how to fix it, they are almost always wrong. - Neil Gaiman

Trust people but also trust your own judgement.

How to Ask for Feedback

Feedback is very important but you have to know how to ask for feedback to get good feedback.

“Do you have any feedback for me?” seems like a good way to get feedback but as you will see it is probably the worst way to get good feedback.

The following are some thoughts on how to ask for feedback in a way that can get past peoples natural hesitancy to be critical and find some deeper insight.

People dont like to give straight up negative feedback, even if they think it. So the best requests for feedback allow people to give a praise while then revealing what isn’t working for them.

For example if you were getting feedback about a article asking the following would be too open ended to give value, “What did you think about the article? Is there anything I should change?”

Instead you could ask, “If you were going to cut 20% of the article to give the reader focus on the best parts what would you cut?”

This couches the feedback in a way that allows them to give credit to the best parts will giving you the valuable info you need. Its important not to tell them what you think the best part is. They may choose to cut the opposite of what you were thinking, so leave that up to them.

Feedback about Yourself

• What is one area you think I really excel at but you think I still have room to grow in?

• If I needed to cut time to focus on something what’s one thing you see me do that I should cut?

• What things would you like to delegate to me but are not comfortable with yet?

Feedback about a Presentation

• Was there any point in the presentation where you felt lost?

• If you were forced to remove 20% of the presentation which would it be?

• If you could only keep 20% of the presentation what would it be?

• Did you pick up your phone or check slack during the presentation? At what part?

Team Feedback

• What was the most exciting project you did over the last week?

• What was the least exciting task you worked on?

• If we had to stop one meeting what would it be?

• What percentage of your week were you working on planned work?

Wrap it up

Getting better at eliciting feedback takes practice. I learned a lot of these tips from a book about game design. Getting feedback is a critical part in designing a game that is fun. I is also a critical part of your growth.

Try some of these questions or try to come up with your own. The key is to frame the feedback such that it allows them to give a compliment while also forcing them to give you feedback about what’s not working for them.

If you liked this, consider subscribing to my Substack. I publish an article about software engineering and software engineering management every Tuesday. If you want even more, consider joining my paid content where I am writing a course in real time about making the jump from developer to manager.

Subscribe now

As a manager, there are lots of things you can do for the people you manage. However, they generally fall into three categories: Feedback, Opportunities, and Resources. Likewise, as a developer, these are the three things you need from your manager. I wanted to call them the Big FOR. That got shot down because it is slightly confusing given that there are only three. But it makes me laugh every time I think of it, and it's better than ROF or ORF, so what are we to do? Naming things is hard work.

Let's get back on track...

We have all been in our 1-1s, and our boss says, "Is there anything I can do for you?" or at least I hope your boss is asking you that. Your answer to that question will fall into one of these three buckets. However, I often get the answer, "No, I'm fine." While this is a totally reasonable answer, it is a huge missed opportunity because your manager is the best person to provide the things you need.

If your answer nine times out of ten is "I'm fine," then it probably means you do not have a plan for how you need to improve. If you had a plan, you would know the things you need to get to the next level, and you would be prepared to ask for them.

Let's dig into each category.

Resources

Resources are the physical and digital things you need to get your job done. These might be the tools of your trade, such as a powerful laptop and an IDE. In the modern world, apart from your device and the IDE, most other resources are provided through access. This includes access to a cloud account, a sandbox, or a third-party tool. These are all the basics you need to do your job.

Once you have the basics, you can start thinking outside the box. For example, AI tools for software developers have emerged overnight. I'm sure many developers had to educate their managers on the value and work hard to obtain that resource. Or maybe you need a dataset for training your own AI models.

Another significant component of resources is access to training. Training is an area where having a plan is really important. There will be training that your manager or HR requires you to take, but often it may not be strategic training.

You need to map out your strategy and identify the training resources you need to reach your goals. Obviously, you can breeze through the required training, but if you can access quality training, you should take your time and take full advantage of it.

The good thing about resources is that, if necessary, you can acquire them yourself. In some cases, this might be required. That's why this is the least important of the big four. In the end, you might need to spend a few bucks, but you can make things happen here if necessary.

Opportunities

Opportunities are chances to put your skills to work. There are tons of different types of opportunities, but they generally fall into 2 categories: presenting and leading.

Presenting is about communicating your thoughts. One of the major forms of presentation is speaking. Speaking is not just something you do on stage in front of a crowd. It can be as simple as explaining a concept to the team or a manager. It can be as big as doing a demo for the whole company. Speaking is a great opportunity, and you need to be able to speak and present your thoughts clearly to be a good leader.

Writing is another form of presentation. Writing may be in the form of a blog post or a technical specification. It can be documentation or an email. Regardless of the form, these are key opportunities for you to grow. Writing allows you time to think through each word. It's a lot more approachable for developers, but good writing is difficult and should be taken seriously.

The second form of opportunity is leading. Leading can also start small. It might start as leading a small project or taking point on a feature. But it can lead to running whole teams and taking point on the most critical projects.

Another thing your manager can do is leverage the business to get you incredible opportunities. There may be speaking engagements that the company would like to send someone to do, but they just don't know the interest. Your company can leverage those relationships to give you opportunities, but sometimes you have to make the first move.

Once again, it's important to know your objectives and have a clear strategy for how you plan on getting there. This will allow you to ask for the leadership opportunities that will best take you on the path.

If you are just going from one opportunity to the next, you may be missing more key opportunities. Saying "no" to some things will enable you to do other things and do them well.

Feedback

Finally, the last thing your manager can offer you is feedback. This is perhaps one of the most beneficial aspects of working with your manager. If you have a good relationship, you can receive valuable feedback about yourself if you know how to elicit feedback. Being good at prompting feedback is a whole post in and of itself.

There are lots of places where you can get feedback. Every conversation should give you feedback. However, there are two main kinds of feedback you should be looking for from your manager.

The first is performance feedback. Obviously, this is the main feedback function the business is looking for, so every manager will give this kind of feedback. Managers are not always great at giving feedback about performance, so this is a great opportunity to step up if you are struggling to get on the same page with your manager about your performance.

Once you are communicating really well about your job and if you are meeting and exceeding expectations, then you can shift your attention to coaching feedback.

Coaching is about working through specific issues. Even if your manager isn't particularly good at coaching, the act of getting feedback about leadership scenarios you are working through will be valuable for you, and it will signal to your manager that you are open to feedback.

Ask your manager their opinion about the things you are struggling with and see what kind of advice you get. You don't have to always follow it, but it's good to lean on their experience to get feedback.

Conclusion

I have only provided a few examples here. Think about it for yourself and come up with your own list. Or if you are following along in my course, use Wardley Mapping to identify the areas you need to improve. There are things we all need to get our jobs done, but often we lack the strategic foresight to ask for them.

Most people expect resources, opportunities, and feedback from their manager. I believe you should be proactive in eliciting these things from your manager. Guide them to provide you with the necessary tools to accomplish your tasks.

If you liked this, consider subscribing to my Substack. I publish an article about software engineering and software engineering management every Tuesday. If you want even more, consider joining my paid content where I am writing a course in real time about making the jump from developer to manager.

Subscribe now