Communicating a Pronoun Change

I had an interesting experience recently and as it was new to me, perhaps you too can benefit from this experience.

The meeting…

Myself, my direct report, a representative from human resources and an individual contributor reporting to said manager. Frankly, I was concerned that there was either an egregious performance issue or HR violation I was going to find out about. As the headline to this article states, it was about an individual working for me who wanted to announce a change in their pronouns. 

I wanted to share how I went about communicating it to the organization. It is tempting to venture into the current politics of this situation especially if one has strongly held beliefs. My take is that as a manager my focus is on results and the people who deliver those results. This employee made a request of me and it was easily within my power to support them. So, I tried to help.

The request…

One more facet of this request: the employee requested that their manager send out an email to the team announcing the change. I don’t know if there is a defined standard, but I strongly encouraged the individual to send their own note out. They were insistent on it coming from us (management) and as I was reading their manager’s body language, I could tell they weren’t comfortable writing the email either. So, I took it. It was a task that (I thought) wouldn’t take me long and was a good opportunity to ensure I set the bar for the cultural conventions in my organization. 

Oy, writing this email well took me a while. I spent time looking for examples and learned that most were about students introducing their pronouns and chosen names to their professors. This is a good sign for us thinking we need not venture into this subject that questions around pronoun usage are not going anywhere and we’d better figure out how to support our teams. I want to restate that to many typical individuals the importance of this may not be easy to grok. Leaders must set aside our comfort and focus on putting together a team of people who feel safe to tell us what they need to perform at their best.  

The email…

Hey team,

I wanted to send out a note about a pronoun change for one of our team members: [Name]. [New Pronoun] requests we refer to them with the [New pronoun likely one of: (she/her|he/him|they/them)] pronouns. 

Please do your best to help us embody our company value – [add your value here] and support our team cohesion as we give all our team members the respect to refer to them with their name pronounced accurately and use the pronouns they prefer.

Lastly, I wanted to suggest that we more broadly share this link: (Link to an Airtable including columns for: name, nick name, pronunciation guide for name, pronouns, gender, time zone, country, start date, manager, specialty, etc.)

You may not have seen it before, but we try to track some basic demographic information to help us better understand our team and their backgrounds. In it you can add your pronoun preference and a helpful pronunciation guide for your name.

Note: These fields are designed to be user generated. If you don’t see appropriate values to reflect your identity, please DM me (@Nathan Feger ) or your manager (if you don’t already have edit access) and we will get this sorted out tout suite1.

Take care,

Nathan A Feger

The takeaway…

Big shout out to my son who was helpful with some references to sites that helped me understand pronouns and neo-pronouns. As well, he is someone who helped me develop greater empathy for these individuals’ experience. 

You will notice in this email that there is a reference to not only this pronoun change, but a systemic approach to helping craft a culture where individuals are addressed with respect. My company had more than 10 time zones to take into account across many more cultures. What unlocked this email to me was that this individual was just one among many to whom I am not addressing properly when I misspeak their name, or expect a response from them at 3am. 

Good luck, and if you use this email please holler at me @nafeger on twitter to tell me if it was helpful or if you think it could be made better.

1 This turned up in a good discussion with some of my peers and it bears repeating here. Some solid feedback is that this phrase will not translate well to the many cultures mentioned in this article. Further, it could be described as ‘not professional’. All of which is true. And it would be totally reasonable to remove and replace with a more generic vernacular of: right away. Yet, this kind of flourish is part and parcel of my style, and a quick search or even context clues reveal it’s meaning. ‘Professional’ doesn’t have to be boring, stale, or lacking the personal. It is all personal, this more than most. So, I’ll leave you with two thoughts: 1. Communicating well takes time and has consequences. 2. It doesn’t have to suck at work, so be yourself as much as you can. Which is really the lesson this individual is giving us all the opportunity to learn.

Homework #2 – Focusing at the ‘top’ and ‘bottom’ of the organization

Thinking about the ‘top’ and ‘bottom’ of an organization

This week we have two podcasts for your listening pleasure.

There is a lot of interesting takeaways from this first a16z podcast. To me the systematic approach Chris Power takes to how he thinks about his company is a valuable framework as one moves out of the individual contributor or even front line manager role into an executive.

The next podcast thinks about things in a totally different way. Michael Lewis’ podcast Against the rules has an episode: Six Levels Down, which reminds us that sometimes the ‘bottom’ of the organization is where the real authority lies. Here we see some examples of the highest paid, most visible members of an organization fully incapable of getting it unstuck. To me it’s an important reminder of where I came from and who is really getting work done.

The goals of these homework assignments isn’t to provide any sort of answer. It’s an opportunity to discuss with your peers, or team members and see how these discussions affect your current efforts.

Take care,


The self-taught programmers guide to moving up

I am a self taught developer. I had the benefit of a dad who gave me a computer and helped me write some programs. The TI-81 and TI-85 calculator were the laptops of my school days. I spent many days staring at the manual for that calculator as I learned to program a solution to physics problems. I turned out to be better at coding a solver than actually solving the raw problem

I only had a couple of college classes before I dropped out; the most important of which was data structures. This class unlocked actual programming to me. During this class, I started a small company with a friend of mine and dropped out of school. If I could not figure something out I would go to the bookstore and buy a book adding a new tool to my toolbelt on an as needed basis.

Then my company went out of business…

I was lucky enough to land a job at a small software company just after I turned 21. Until this point I’d never worked on a system I hadn’t built though I was a couple of years into my programming career. It was humbling to spend the first couple of weeks trying to get the local development environment up and running. With some help I did, and I was eventually able to contribute code to that company. 

The hardest lessons came when I decided it was time to move on from that company. I spent two years interviewing at different places trying to find my next position, and learned that I was only likely to get a job offer if the hiring manager was themself also a self-taught developer. These were some very hard times for me. And I am pretty confident that I am not alone in this feeling. 

Feeling stuck because the coding interview feels insurmountable is a rough. It can feel like the next career step is just too high. This was the process I went through to help make my interview efforts a bit more successful. Being able to interview well enables folks to stay where they are because they love the work and not because other opportunities are  out of reach. I hope this process will help lower the stress of interviews and improve the success rate. Lastly, I found it to be useful at my job to add in a bunch of tools I never knew existed.

The first step in starting an interview process is to realize it can be very stressful. You will likely have some poor interview experiences. I found myself leaving interviews questioning my worth in the world. I generally try to take this opportunity to remind myself:

  1. Interviews and interviewers are as flawed as I am.
  2. I know I am capable of delivering value.
  3. I am a good person and this is true whether or not I “pass”interview is 

Whether or not I connect with the interviewer’s interpretation of my performance. I am (you are) worthy of this profession regardless of a single or string of unsuccessful interviews. 

I initially did too many interviews to count but I recall getting about 2 offers after 10 on-site interviews. This was a lot of work for a meager payout (even the offers I got were a low comp). 

A former mentor gave me a push in the right direction and I was able to move to a new position. The skills I learned to improve my performance during subsequent interviews have stood up well in the many times I have been either the interviewee and interviewer.

Take that algorithms course 

I took this Algorithms Course on Coursera by Tim Roughgarden though it is not the only choice.  This course takes time to complete and for me forced me to face some of the hardest challenges I’d ever faced in my programming career. This course helped me to overcome challenges and grow in my capacity and confidence. Taking this course will not only allow one to put a crack in the wall of the coding interview, it will be the nexus of much of the rest of the advice in this article.

When I was first interviewing and got algorithms questions, I was paralyzed. I hadn’t needed them in my day job and hadn’t learned them. Further, when I’d press interviewers about where they used a particular algorithm I never got a great answer. This dichotomy of questions not related to performance of one’s job frustrated me.  Algorithms, like Djikstra’s search, finding a cycle in a directed graph, or descending a tree can be amazingly fun when one isn’t under the scornful or bored gaze of another programmer.

Taking algorithms teaches that: It is fun to write code that can objectively be measured as correct.

Much of the modern web developer’s code isn’t algorithmically challenging to write. Figuring out what to write, dealing with the meetings and documentation and changes in requirements are hard, that’s why we care so much about developers being good communicators. If Product Managers knew what they wanted a feature to do, they could write the code themselves. 

Solving an algorithm based on the scaffolding provided in a course is hard, at least relatively speaking. In fact, this is why for people who’ve studied them, they make for great coding challenges. Typically for an interview one is given a problem that can be solved in less than an hour and the interviewer can infer the applicant’s ability to do an objectively harder algorithmically challenging problem. So, the interviewer infers a correlation to one’s ability to wrangle text into and out of a database.

Studying these algorithms outside the stress of an interview will be like a kata in karate. It gets burned into muscle memory to do something very hard in a low stress environment, when stress is introduced the body is ready.

Taking algorithms helps one learn how to do hard work while smiling

Learning introductory algorithms helps with interviews. It also helps with the day job. One adds a whole new suite of tools to their toolbox. A hand rolled algorithm doesn’t often go into production. But knowing algorithms takes an n-cubed problem and turns it into an n log(n), this might save the company hundreds of thousands of dollars in compute. 

Once Algorithms have been conquered: Learn a new programming language.

Many computer science curricula require engineers to learn several languages. In fact, this is extremely important today as the average developer can find themselves working in JavaScript, TypeScript, PHP, Terraform and probably Go all in a given week. I’m not sure why we (coders) find ourselves in this state, but learning a new language is super freeing. And guess what, you just took an algorithms course, that has some solid correct answers, which you can use as a model to learn the new language.

Try out, early in the first 20 or 30 problems solid math research is required. Don’t let math become the problem focus on coding not math. Work through a few of them in a language you understand well, then pick a new language you read about on hacker news and solve that same problem again. If you throw a couple unit tests on it and a nice README, perhaps it might be a good idea to put it up on GitHub. So an interviewer can see some your capacity at its fullest. Coding in a quiet place with sufficient time is a much better example of ones performance.

Learn LISP.

Lisp is an early programming language (thanks, Wikipedia). It was the second high level language after Fortran from back in 1958. Most developers have only used c-like languages, and this is definitely very different. Further, it’s macro system allows developers to address a problem by designing a specific language for that problem, then coding in that language. Paul Graham explains well the benefits of this language in the linked article. Note: there are many dialects:; pick one. I did Clojure. I haven’t  become a master. I did a few Euler projects and a couple of algorithms so I got a feel for the language. Fortunately this coincided with functional programming making a comeback in Java, and I was able to grok this much faster, having luckily looked at Lisp. (Lastly, if you take this on, one more xkcd comic will come alive for you.

If you are still reading I appreciate it. If you choose to go down this path, you may be approaching the end of the double digits of hours. Remember, this puts you into the arena with individuals who put these hours in while in college or perhaps on their own. If you want to command the top salaries in the world, you need to have the top skills. 

One final topic, and it’s a doozy: Distributed Systems Theory.

You don’t need to know everything about this big topic. However, you are already working on a distributed system. You probably have a datastore, a web server, and a client. Because the speed of light isn’t instant and a connection between any two points in a network can fail. Learning about distributed systems will help you realize that failures will occur, we can know generally about these failures, and if you plan for them you can mitigate the consequences.

Read up on CAP theoryAphyr, has a great blog and if you are extremely brave you can see him destroy many different datastores by forcing partitions upon them. I certainly do not understand all of it, but I have taken away some great lessons.

This is a long journey to undertake. The reward for this effort could end in more money. However, the peach of mind that comes from being a better interviewer is amazing. Interviewing is, and will remain, hard. It requires practice. I would recommend taking an interview at least once or twice per year. Remember we began to improve interview skills so you keep your current position because it is your choice from an abundance and not fear of the unknown. Finally, You will be ready if you are forced to start a job search at a time not of your choosing. 

I’m a great believer in luck, and I find the harder I work, the more I have of it. ~ Thomas Jefferson.

Take care,




Moving to management part 1: Learning about yourself and your team

It is often the case in software engineering that individual contributors (ICs) are looking for guidance on sticking with a technical path or moving into management. This is probably less of a dramatic move than we make it out to be, however, the front line manager has a huge impact on the functioning and happiness of a team (Indeed, 2021). We as leaders need to be extremely careful to ensure we hire and promote people with the knowledge, skills, and dispositions to be successful in that role. 

This article is about a few techniques to prepare an individual who is solidly delivering high quality software to add more management into their repertoire of responsibility. 

Before we begin this path, let’s take a moment to reflect on where your aspiring individual contributor is in their current role.  Are they considered a top performer in their current role? This should not be understated, we are about to add a lot of leadership to this person, you, them, and their peers should all agree this individual has earned this opportunity. Actions speak loudly and as a leader you are about to make a big statement. Next, ask the individual contributor:  Can you reasonably maintain this level of performance while adding on the bonus work that is to come as you test out management?  We are about to add new responsibility to this person, eventually the workload can be evened out to get more reasonable, but this opportunity will be additive to their workload. Just like taking a class at night, this is hard work, but potentially well worth it.

Ultimately, we are trying to set an individual up for success. We want them to get the opportunity to show that getting promoted requires personal commitment. Further, they will have the chance to fully prove to the team they have earned this new role. A great podcast about this is called the 150% rule. It suggests you should be not only contributing 100% of your current job, you should be performing about half of the responsibility of the next role as you work for that promotion. This is about the first step in getting to that extra 50%

Feeling good? Let’s begin.

The first step in moving into management is learning more about yourself and your team. There are some touchy feely aspects to this, however this is an easily measurable goal:

During Q3 I will take a personal DiSC assessment, meet with each of the members on my team and report back to my manager with what I believe each of their profiles to be. 

We start here, because this work will be useful regardless of this project ultimately ending in a promotion.  Specifically, I ask individuals to take a DISC assessment. This is a product similar to a Meyers Briggs, however, it is quite a bit simpler to use and very focused on one’s performance in a workplace. This talks about default behaviors, under stress am I likely to lead by edict or gather consensus to make a decision? Am I going to tell you a story about me or ask how you are doing? These defaults can be trained and coached, and it is great to know yourself and start to learn how to identify your team members.

This has a couple of purposes: First, learn the material. Management is about improving the flow of information on a team and understanding that communication only happens if the recipient receives the information in the manner you intend is essential.  Knowing yourself and your team makes this possible.  Further, as an individual contributor one can often get away with not being a great communicator to everyone, there’s usually a manager to help smooth out these rough edges.  As a manager there is nowhere to hide.  Not only must this IC build a solid report with each member of their team, they will need to smooth out intra and inter team communication on a regular basis.

The second reason is to figure out if the IC taking on this task likes it. Moving into management requires learning about people, psychology, and sociology. If this feels onerous, management might not be the perfect next step in one’s career… at this time. 

As a manager assigning this work, you may want to recheck some of this material to make sure you are up on it. The great opportunity of your direct reports leveling themselves up means you too need to stay out in front of the content they are consuming. Doesn’t mean you need to be perfect, if your relationships are sound, this is a great opportunity for Iron to sharpen Iron.

Take your time on this one, learning about oneself and one’s team can take a little time to make sure the team feels like they aren’t just rungs on a ladder.  This should lead to some solid one-on-one discussions about how interactions in meetings, through slack, and if you are lucky, in person communications should be changed based on the individuals interacting with this aspiring manager. 

This is just the first step on the path to management. Next, we’ll look at a set of books I ask my managers to read as they start to be responsible for the output of a software delivery team.

Twitter Discussion


    1. The effective manager– The book that really underpins a lot of these ideas 
    2. DiSC basics podcasts
    3. One-on-one deep dives
  2. DISC assessment
    1. Manager-Tools Complete Profile (Paid)
    2. Tony Robbins (Free)

Principles of Metrics Driven Management

It is certainly in vogue to use metrics to drive management decisions.  This is especially true in a distributed workforce.  There can be no pretending my team is working as I stroll by their desks late into the night.  In fact, my personal preference is to be remote from my employees to ensure I do not judge them by which of us leaves the office later at night.

Metrics can be pretty difficult to use. So, before you get any further into this, if you are unfamiliar with Accelerate: The Science of Lean software and Startups.  You should almost certainly familiarize yourself with their data driven approach and come back to this anecdotal piece after.

If you are still here then thanks.  My struggle with metrics for years in software is that most metrics appear objective and in fact are quite subjective because the target is subjective. Look at a simple metric like: Did this feature get delivered on time? Well, navigating the minefield of the quality, the actual vs expected team size, the actual vs. expected scope delivered.  All open multiple cans of worms for something that on its face seems simple. 

So, instead of giving up, I have a few principles that I like to apply to metrics used by my team.  Then in the future we can walk through some of the metrics I use on top of those defined by Accelerate.

1. Requirements Driven

This may seem self evident. However, I have rarely seen clear documentation on exactly how one specifies a requirement before it is driving team member behavior. For example, escaped defects is a metric teams like to use.  However, different executives care if those tickets are tied to support tickets or not. i.e. if the customer hasn’t found the ticket, then perhaps it’s not that severe.  Perhaps a defect only counts if it is within a key workflow path.  With a bit of brainstorming there are probably even more facets we should at least consider.

None of these specific facets are complicated to implement, yet if we do not think through them we will not be speaking the same language.  This is extremely important in all teams and even more so in a distributed environment.  Silveira in Building and Managing High-Performance Distributed Teams: Navigating the Future of Work talks about an explicit North Star so that team members can make decisions alone because they understand the direction the company is taking.  This metric example may seem too small, but not writing down the exact specification for a metric can either lead your team astray or just as bad accidentally lead you in the right direction which will reinforce this incorrect behavior.

We expect detailed docs to write code for our customers, it is reasonable to request this of the metrics we are measured by. In fact, opportunities arise when we treat these at first order features.

2. Produced via code

We are measuring software engineers, engineers generally write code to make money.  Our metrics should be built via the tools to which we are accustomed.  If I want to measure deployments or MTTR, then I should be able to view a report in Excel or Google Docs, or my favorite Airtable and see real time data about how things are going. 

Here, we are standing on the shoulders of principle 1.  If there are not requirements for how to calculate a metric, then we will be unable to manifest that requirement in code.  Further, if we find that even with good requirements the data doesn’t exist cleanly to produce the metric.  Then we may need to think more deeply about our processes because there is likely a misalignment.  This is great news.  Finding out in December I missed my bonus because of bad or missing data is way less fun than finding this out in January when goal setting is occurring.  Then we can determine if spending the time and energy on a new metric is worth it, because these aren’t free and will likely displace some customer work.

Like we ended section 1, this is not meant to deride data or sound like this is insurmountable.  But wrong data is probably worse than no data and respecting that engineers and managers all have only so much time in a week goes a long way towards building a culture of sustainably delivering high quality business value.

3. Balanced

Balancing metrics happens across 2 dimensions.  The first is attempting to measure countervailing forces to ensure we are not swinging too hard to the side.  For example if features are all being delivered on time, but Customer Satisfaction (CSAT) is down and defects are up relative to a baseline… Then perhaps we are not sufficiently focused on delivering a whole package of value to our customers:  Software that is both regularly updated and high quality.

The second dimension is considering both absolute and relative changes.  Let’s presume for a minute that I look over 2019 and 2020 escaped defect counts and I see that there is a 50% increase in escaped defects.  All things being equal that could be an indication of a problem.  However, if we also consider that the team size grew by 100% over the same time period, this could actually be a great number, as we are seeing new developers entering the system reducing our rate of defects per engineer. 

Balancing metrics is definitely more art than science.  It also has a tendency to push us towards many different metrics.  I would suggest that a general overview can probably be done with a single digit number of metrics, this can reasonably be kept in everyone’s heads and can capture quite a bit of context.

4. Visible to all

Metrics should be placed where those they are measuring can see them. In fact, not only should the dashboards exist in an appropriate location. (Not necessarily a TV hanging over everyone’s heads, but at least on confluence or somewhere clear) But referring back to principle 2, the code should be open to the team as well.  These are highly paid knowledge workers and as you start coding up metrics, you may find, as I have on many occasions that bugs can be introduced.   This openness also aligns team members to the North Star, and does it speaking the programmers’ language: code.

Which leads us to the last principle.

5. Continuously Improved.

Metrics set about to codify the goals of the organization.  Those goals can change, the measures we set out to hold ourselves accountable to may not actually drive the behavior we desire.  They can even be buggy.  We should expect the people to whom these goals are being applied should be able to suggest updates, make those updates, and see how their hard work is in fact ‘moving the numbers up and to the right.’ 

Closing Out

Metrics are an opportunity to drive trust and empowerment within our organizations.  Often times they are used to limit bonuses or shepherd employees onto performance improvement plans.  Just because they are often used poorly does not mean we as leaders cannot turn the ship a bit towards success.  It is very likely the case that your organization is predominantly doing a great job.  Do your numbers expose this?  Do they provide opportunities to give praise to your teams and team members doing the great work that is keeping you employed?  Further, are you able to foster feedback from your team that some metric is leading us away from our North star?  When that happens you will know that you have fostered the trust and collaboration that not only drives grow with in an organization, but serves a key countervailing force: It doesn’t have to suck at work.

Take care.

Twitter Discussion

Homework #1 – Management has Consequences

It’s not a lot to say one is a fan of podcasts, so with the homework series we can travel together though some of my favorite podcasts and perhaps from this we can leave a trail of something novel on the internet.

The first assignment is to look into Reply All’s episode on Bon Appetite.  The podcast is #172 The Test Kitchen.

When I first heard this it hit close to home, here is a set of white guys at the top of an org with little to no appreciation for the turbulence they were causing in their org due to them not appreciating the effects their role power and biases were causing.

Today I am responsible for 40 engineers, and their performance impacts the performance of quite a few additional people and customers.  I have often found myself leading the team astray or causing issues because of mistakes, misunderstandings, and poor assumptions on my part. 

In fact I developed one of my most important principles: Nate doesn’t change the plan in standup, as a remediation for my behavior in the past. We’ll have to revisit this in a later article, but the short version is that the blinking sign above my head as a manager can often accidentally be used to redirect a train that was humming along just fine without me butting in. Back to the podcast.

What’s profound about this podcast, is not only did it try to highlight this issue with management at the magazine, it uncovered this same behavior within the Reply All podcast team itself. So, now we have not only a case study of this magazine, but in real time we can learn from an organization coming to appreciate how hurtful and disruptive this behavior can be in any organization if we are not actively examining our impact.

Your homework, should you choose to accept it, is to listen to this case study (this will take a few podcasts) and see how you as a leader are perpetuating these same issues within your org.  Then take it one step further and see if you can illicit from your team honest feedback about where you are leading the team towards this same cliff. 

Just be aware as we (managers) ask for feedback, take our time and know that if we haven’t laid the groundwork of trust and felt safety, we will get nothing.  If we get nothing, it’s unlikely that is because nothing is wrong.  Further, it is not our team’s responsibility to give us feedback, traditionally feedback rolls downhill, we have to use our relational power to dim the blinking manager sign above our heads.  And ask with a penitent heart for the opportunity to help grow together as a team.

10 2-hour blocks per week

Individual Contributors in an organization need time to get work done.

This feels axiomatic, yet it is often the case that any number of meetings can gather on an individual’s calendar such that there actually isn’t enough time to sit quietly and think the deep thoughts one needs to deliver business value. Today is not the day to wax nostalgic about how terrible meetings are and how we should have no meeting Wednesdays. Meetings are not intrinsically bad and neither is their absence.

However, as a leader it is my job to ensure my team has time to think. To do this, I ask them to look at their schedule at the start of the week and before standup every day and ensure there are at least 2 – 2 hour blocks every day and 10 – 2 hour blocks each week that are unallocated. This can seem like a pretty low bar in an eight hour day, but I would suggest that this is a place to start that is measurable and actionable.

So, on any given day that an IC doesn’t have these two free windows of time. That counts as a blocker in standup. This is really what standups are for; status updates are great but removing blockers is the real money maker. As the manager on the team you just had a person tell you they cannot get their work done. And perhaps even with enough time for you to act

Now it’s time for the manager to step in. Can some meetings be skipped or rescheduled? Or are we writing off this day as one lacking full productivity assigned to the in progress work. It will almost always be a hard decision, but if you don’t know about it. If there is no stake in the ground, you cannot hope to train your team to help them help you identify this concern.

Bonus points: This can be systematically measured. Outlook and Gmail both have APIs that can help you query your team members calendars so that a metric can be built around what percentage of your team has unblocked time. 

Lastly, not all Specialties in an engineering organization get the same amount of free time. As a team lead one might only get 4-6 free blocks a week depending on how much planning is happening. A manager or director could have 2-5. So, as you are digging into your directs and skip level calendars be cognizant of their particular role and how focused on coordination it is. (See High Output Management where Andy Grove talks specifically about how he is in meetings all day, because he is their to coordinate and scaffold decision making)

Take care,


See also:

Twitter link for discussion

Empowerment through process change

I spent quite a long time in my career hating processes and actively fighting against it. This is a fairly acceptable approach with a small team and as someone who likes talking and saying the same thing over and over again. This is me. I love to hear my own voice and I used this as an opportunity to engage with my team members. 

This worked great until two things happened: 1. my organization grew to three teams and 2. I was lucky enough to have a boss that said I can only enact processes that I wrote down. I fought this pretty hard until I realized my team wasn’t getting a single message and I was engendering conflict as different people received different messages from me. 

It is extremely frustrating to find out I was the cause of contention in the org I’m trying so hard to build into a caring, constructive, high performing team.

So, here’s my suggestion for building a more sustainable, empowered, and better aligned culture through writing.

Let’s take a detour to empowerment through process. One issue I’ve fought with process changes is the feeling it is handed down from on high with nary a consideration of the lowly individual contributor whose life is actually impacted by this change. This too needs to be addressed.

Step 1: Write down the change you want to make before you take it anywhere near your team. I don’t mean to preclude brainstorming and musing. But keep it away from a wider audience until you can get your thoughts formed enough to write down. Spend the time here to think through the language and grammar of this change. This is a chance to model the behavior we are building to throughout the organization.

Bonus points if your process includes some measurable metric that can tell you whether or not this was actually a good idea. This can be harder than it seems, so don’t make it gating.

Now we test how empowered a culture you are a part of.

Step 2: Put the doc in a place that is visible and editable by your team and prefix the doc and title with ‘Proposal:’ Make sure everybody knows the doc is at the rough draft portion of this endeavor.

Bonus point: Did you detail how you roll out this process change? What day does this start, what docs will be updated? When will employees be expected to conform?

For me that’s putting the doc confluence and dropping it into a chat room #squad-process-changes

Using a wiki or slack is really just tactics. The key is there is one source of truth that can be commented on publicly and even changed by those who are affected. So, give the team a few days, coach them that they should raise any concerns (give a timeline for feedback) and ask for sign off. A manager’s output is only the sum of the team they run so getting buy-in is powerful.

So, in a perfect world, you’ve got a process written down, vetted by your team and it’ll either now be the new way the world works or you will know without a doubt that implementing this is going to be an uphill battle.

All of this is much better than a surprise email your team receives from you about another crazy change they didn’t get a vote on. Oh, and the next time you find your team members arguing about the process they can point at a doc and even change it if it’s due to ambiguity. (But that’s another process change)

Some further reading:


A little about me

I am a few things of note for the purposes of this site:

  • A manager of software development teams
  • A person with a passion to care for the people who work for me

Hopefully, you’ll find something here of note that will help you as this has helped me.