Marzhill Musings

Coding Agents on Teams

Unknown — Mon, 01 Jun 2026 00:00:00 +0000

Coding Agents on Teams</h1>

Introduction</h2>
Unless you have been living under a rock over the last year you are probably aware that AI agents have taken the software industry by storm. It has become clear that a coding agent can deliver software to varying levels of quality in timelines that are accelerated compared to what your average developer could deliver. It's not a magic bullet for speed or quality but it can be a useful tool and it's not likely to go away. Regardless of what you think about these things they are going to be a part of the job for the foreseeable future.</p>
This essay is not going to talk about how to get the best results from a coding agent or opine on the level of quality they produce. I have opinions on these things but that will probably have to wait for a later essay. This one is an attempt to forecast the impact of these tools on software development teams, and how those impacts shape an organization's ability to scale their use. Most of the attention so far has gone to what an agent does for a single developer. The more interesting questions are a level higher, where a team has to absorb everything those agents produce.</p>

Team collaboration as a limiter on speed</h2>
Before agents came along we knew that collaboration and coordination was a major time sink of engineering teams. Most developers didn't spend 8 hours a day 40 hours a week typing into an editor. They discussed architecture, hunted down requirements, UI mocks or wireframes for that feature they needed to get done or reviewed their colleagues' code and sought out code review for theirs. The larger the team supporting a product the more communication overhead they experienced. This overhead, perhaps accidentally, helped to ensure that everyone was moving in the same direction. They had the same standards for the code and architecture. They were solving the same product problems. They followed the same UI standards.</p>
An agent can produce code that compiles and runs for some set of happy paths much faster than a human dev can. This means they will, without coordination, entice a dev or a team to keep pushing on. Just one more feature... honest.</em> This tendency introduces a risk that the team will start fragmenting the codebase and the various approaches over time. The longer the dev + agent goes without touching base with the rest of the team the higher the risk that the code will go astray and need fixing up. The fix is to speed up the cadence of collaboration to keep up. Agents add communication overhead more than they reduce it. The amount a team needs to coordinate is mostly set by the work itself, not by how fast anyone can type. What agents change is how quickly that work turns into code, and how much of it each dev and their agent decide on their own before anyone else has a say. So you don't end up with less to coordinate. You end up with more of it already built, in directions that don't line up, before anyone has talked. Untangling that after the fact costs more than it would have to stay in sync as you went.</p>
To make matters worse, instead of Janet and George getting on the same page it is now Janet's agent, Janet, George, and George's agents all getting on the same page. In my own experiments this overhead only grows the more people you introduce. At some point the coordination becomes a hard limit on how fast you can go. This is not to say that agents won't increase your velocity. They do. But it is at the cost of higher collaboration and communication overhead.</p>

Agents have distinctly average to poor design and architecture instincts</h2>
Out of the box a coding agent is unlikely to have good taste when it comes to the architecture of your system. They are very much the average of opinions of the public internet's discourse on good system design. As a result their opinions are often wrong but not obviously so. Further complicating it is that many of your developers will have varying opinions on the subject, not all of them agreeing, and they will steer the agent with those opinions. Sometimes intentionally and sometimes just from the way they structure their requests. The result is that no two devs with an agent are going to produce code with the same architectural guiding principles. You can't encode enough of that into your system prompts to make it happen. Getting good results means you need code review against a documented standard and frequent coordination between your devs and the product team.</p>
Impact isn't truly understood until an artifact exists</h2>
A lot of design and architecture decisions can't really be judged until the code exists. You can argue about an approach in the abstract for hours and still not know whether it holds up until you've actually built it. Building it used to be slow, and that slowness was its own kind of safety net. You'd find out an approach was wrong gradually, while you'd only committed a little to it, and you could adjust course on the fly without much risk. Agents made building nearly free, so now the cheapest way to find out if an idea works is to just have the agent build the whole thing.</p>
For one person poking at an idea on their own, that's can be a good thing. On a team though, every one of those explorations lands as an artifact someone else has to read, understand, and reconcile with everything around it. The loop is addictive, and a lot of developers are solitary by nature anyway. They will easily rearchitect half the application and land a -2000, +4000 edit change in a PR for someone to review without even realizing it. They may only have spent a week on it, but it may be a week of lost work and wasted token spend because the PR went in a direction the tech lead happens to know won't work. Building got cheap but understanding what got built didn't.</p>
The workflow loop is a slot machine</h2>
The startup cost for a new feature, bug fix, or refactor for that new idea you had with an agent is remarkably low. Without even realizing it, your team members can find themselves churning out code they barely understand, going back and forth with the agent, feeling productive but massively disconnected from what they are producing. Like any good slot machine the reward is unpredictable. Sometimes you pull the lever and get exactly what you wanted, sometimes you get garbage, and that uncertainty is what keeps you pulling. There is no obvious offramp from the work. The machine never tells you to stop, and the perfect feature always feels like just a few more tokens away. This creates a high risk for burnout.</p>
The machine has a second way of getting you. The moment you slow down to question what it produced, push back, or ask for changes, you start to feel like you are the roadblock. The machine is fast, and you, with all your opinions and questions, are what's slowing it down. So you're tempted to just give the agent full freedom and get out of its way. Never mind that those opinions and questions are the actual value you bring.</p>
Humans are bad at multi-tasking</h2>
There is a strong temptation to celebrate or encourage people working on 5 different things using 10 agents at once, constantly switching back and forth to keep all the agents busy. It feels like a huge multiplier but it has a human cost. The thing that actually limited you was never how fast the code gets written, it's how much of it one person can pay real attention to, and that part doesn't get any bigger no matter how many agents you add.</p>
An agent will happily sit and wait while you go look at another one. You never get a natural brake limiting your activity. No one is good at keeping that much state coherent in their head, and every time you switch you pay the cost of loading it all back in and you don't notice you're paying it. They may feel productive while the attention they can give any one agent quietly drops below what it takes to catch the things it gets wrong.</p>
The agents are working in parallel, but all of that work has to come back together through one person, and that person is the dev. They are the point everything has to synchronize through, and the place it shows the strain first is the back and forth between them and each agent. You can only really take in what one of them is telling you at a time, so the more agents you run the less of each conversation actually lands. The code keeps coming but less and less of it is actually getting looked at. Quality goes down, the divergence and communication problems from earlier only get worse, and burnout is just around the corner for any team doing this long term.</p>
Agents crowd out communication</h2>
You've probably been the recipient of a massive wall of text from someone that used an LLM to generate it. They want you to read it and give feedback or respond or take action in some way. The prose however is overly long and ingratiating. The last thing you want to do is try to read and understand it. You probably fed it to an agent so that agent could summarize it for you. Before you know it your entire team has stopped thinking. They are just a glorified messenger service for each other's agents.</p>
The trouble is that the thinking was never separate from the writing and reading. Working out how to say something clearly is how you figure out what you actually think, and reading someone's attempt is how you actually engage with what they mean. When one agent writes the message and another agent reads it the words still get from one person to the other, but the understanding that used to come with them never forms on either end. The communication still happens. The thinking it was supposed to carry quietly drops out.</p>
Strategies</h1>
So what do you actually do about all of this? None of these risks are a reason to avoid agents. The teams that come out ahead will be the ones that recognize these risks and build their habits around them.</p>
Most of it comes down to engagement. Choose tooling and approaches that pull your people toward the work the agent is doing instead of letting them drift away from it. Instead of using an agent to generate a wall of text, tell it the message has to fit in a paragraph of fewer than ten sentences, so a human still has to decide what actually matters. Keep the units of work small enough that someone can hold them in their head and actually review them, and get feedback early and often. That might stretch a week of work into a week and a half, and the speed won't look quite as impressive, but the output won't be wasted. The feedback that matters most still comes from other people. Talking to an agent is not a substitute for talking to your tech lead.</p>
Because no two devs and their agents will land on the same architecture on their own, you have to give them something to converge on. Write down the standards you actually care about, the architectural ones as much as the stylistic ones, and review code against that standard instead of against whatever each agent happened to produce. Pair that with frequent coordination between your devs and the product team so everyone is steering toward the same place. The agent won't find the shape of your system for you, so the humans have to own it.</p>
Be careful about how much you ask any one person to run at once. One developer shepherding ten agents across five different features is probably an anti-practice, not a thing to celebrate. And because the work no longer stops on its own, you have to build the stops in yourself. The lever is always there to pull, so decide ahead of time where the offramps are and make it normal for people to take them. Protecting your team from the machine that never tells them to stop is part of the job now.</p>

Cultural Christians, Aren't

Unknown — Thu, 13 Mar 2025 00:00:00 +0000

Cultural Christians, Aren't</h1>
There is a growing trend for certain groups of the US to refer to themselves as Cultural Christians. What they mean by this is that they like the aesthetics of certain parts Christian moral precepts and cultural norms but they don't want God in the mix. It may sound as if those people are natural allies of the Christian politically. I am not so sure that is the case though. Its not clear to me that christian moral precepts can be safely adopted without a faith in the God who handed them down. That moral code is a full package. The Ten Commandments start with an admonition to worship only God and to put nothing else before Him. The entire basis of the moral code flow from obediance and worship of God. When it becomes divorced from God tragedy ensues. History is full of examples where cultural christianity was used to justify very ungodly activities.</p>
The Risks of Cultural Christianity</h2>
A purely cultural christianity comes with risks that are inherent to the absence of God acting as the safeguard. If it is not rooted in a continuous active pursuit of God it becomes unmoored from the very things that make it work. While cultural christians may occasionally align with us on specific issues they fundamentally can't be expected to intrepret those issues with the entirety of scripture in mind. They aren't motivated in the same way. Their end goals are not the same.</p>
Goals and Motivations</h3>
Christians are meant to be intrinsicly motivated by their faith and relationship with God. This is why the Ten Commandments start the way they do. The entire system is meant to be approached with the basic question. What would God have me do in this situation? They are not just</em> a set of rules but a philosophical collaboration with God that motivates our thinking and desire to conform to them. To conform in a way that considers the whole of scripture. Not just the pieces that meet our desired cultural expectations.</p>
Ultimately a cultural christian is just adopting the parts of christian culture that appeal to them at this time. They are not approaching our cultural norms with a desire to conform to Christ. They are trying to conform christian culture to their own. They do not share the same end goals so it is inevitable that eventually they will be at odds with us and with God.</p>
Picking and Choosing</h3>
Without the inherent intrinsic motivation of the christian faith then the temptation to pick and choose from the moral precepts and cultural norms will inescapble. You won't have a strong foundation to motivate what you keep vs what you leave out.</p>

Organizational Change

Unknown — Fri, 16 Jun 2023 00:00:00 +0000

Our industry, like any other, is prone to fads and trend following. Sometimes the fad is positive, sometimes it's neurtal, and sometimes it's misguided. Adopting a fad just to follow the crowd is almost always a mistake though. The fad around having DevOps, SREs, instead of SysAdmins is an example where many companies are adopting a trend as a way of following the crowd. Companies of a certain type of engineering culture get a lot of value out of having SREs and/or DevOps. But just as many companies fail to properly implement those roles or teams. It doesn't help that the job descriptions often get muddled and end up with overlap across companies.</p>
This trend can often get traction at a company because of real problems they might be trying to fix. Those problems could be something like the following:</p>

Unreliable software in production.</li>
Slow delivery of software changes to production.</li>
Long time to remediation during outages.</li> </ul>
These are real problems that companies have and DevOps or SRE teams are often seen as a way to fix those problems somehow. If the company isn't careful though they can adopt the team as a cargo cult going through the motions out of faith rather than an actual understandng of the sources of the problems they are trying to solve. As a result those teams and initiatives are set up for failure. The problems are important to solve though so if your company or engineering organization is experiencing those problems there are some strategies you can use to attack them.</p>
Articulate the problem clearly</h2>
If the problem is unreliable software in production, then make sure you articulate that clearly. This doesn't mean just stating the problem but also how you are measuring it in some way. What are the indicators of unreliability in production? How do you count instances of unreliability? How far do you want to move that count of instances in the future?</p>
If the problem is slow delivery, then how slow is that delivery? What is your mean time from start to merge? What is your mean time from merge to production release? What is your target time for those phases?</p>
If the problem is long time to remediation during outages, then how long is that time to remediation? What is the mean time to remediation? How long are your outliers? What is your target mean time for remediation?</p>
It's important to note that picking the wrong target metric can cause strange outcomes. Measuring the problem is important to understand it but if you misstate the problem and target improvement metric then you may not get the result you actually wanted. Think about this carefully and consider how the team might interpret or even game this metric.</p>
Do a root cause analysis of the problem</h2>
Root cause analysis helps you get to root of the cause of the problem in your organization. Every organization is different. Their structure is different. Their culture is different. Their processes are different. Cargo culting a process or methodology without understanding why they work and how they would fit in your own organization will doom you to failure. Give a thorough analysis of why you are currently experiencing this problem. What parts of your organizations structure, culture, and process contributes to the problems.</p>
This step is critical because it will inform you as to whether adopting a new methodology or set of ideas in the zeitgeist will actually address your problem. It's important to be honest in this step and own the failures in your organizational setup. If you aren't honest about the ways your organizational setup is failing you will not be addressing the real problems.</p>
Prepare to adopt the solution</h2>
The solution to these problems is going to involve changes in at least one but probably 2 or more of the your teams structure, process, and culture. These kind of changes typically are highly disruptive and also can take a while to fully implement and take root. They also involve a fair amount of emotions to those impacted and your leaders will have to deal with the fallout of those impacts.</p>
Structure</h3>
Structural changes appear to be an easy change to make. Create and staff a new team with a clear charter and measure of success. Just creating a new team is only the beginning. You need to empower that team to actually make progress toward success. You will need to be able to articulate their value to the organization in a way that the rest of the organization can understand. They will need processes that support them. They will need authority to make decisions and access to whatever resources they need to make the changes in the organization that they need to make. One of the secrets of success for SREs at Google was that SRE's had complete autonomy to say no to any team who didn't meet their bar for support. They were also incredibly valuable since having SREs meant that you didn't have to carry a pager as a developer or be involved in stressful outages for the most part. The value proposition to developer teams combined with the authority the SRE teams had meant that teams were highly motivated to meet that bar. It was badge of honor to meet the SRE bar and qualify for an SRE team. It was a mark of shame if you lost your SRE team and losing it was entirely under the scope of that SRE teams authority.</p>
Process</h3>
Process changes may be warranted. Planning for them can fall into a few different traps though. Processes need to occupy a happy middle ground between too ridgid and restrictive or not clear and specific enough. Ideally processes have a clear and understandable path from A to B. This may require you to have escape hatches and often means that processes need to be lightweight and well documented in order to be successful. You should expect that you will miss cases so be sure to include a way to propose modification or augmentations. You'll need to balance the tendency for processes to grow without bound by providing a way to trim it. Process improvement is harder than it sounds.</p>
Process also takes some time to become second nature for people. The more complex the process the longer it takes to sink in. Be sure to be realistic and pragmatic about the impact of your changes so people aren't frustrated. It may in the short term increase times for tasks even if the intent is to shorten those times.</p>
Culture</h3>
Note that cultural problems are notoriously hard to fix. Culture flows from the top down so you may need to have some hard conversations with leaders in the organization. Culture is also very sticky once it has taken hold. Consistency and frequent involvement by leaders in changing the cultural principles is going to be key. Hypocrisy on the part of your leaders will doom the whole enterprise to fail.</p>
If your leaders aren't fully bought in on the cultural change then will not be successful. You either need to reconsider the change or in the worst case replace your leaders. If you aren't prepared or unable to do that for some reason then the cultural change is a bad fit for your company and you will need pick a different path.</p>
Conclusion</h2>
There is no one size fits all solution for engineering organizational problems because there every organiation is different in structure, processes, and culture. New teams or new organizational paradigms are modifications of the organization and as such need to take into account all the ways that organization is unique. One company having success with it doesn't imply that you will. You can learn from their experience by understanding what about their own organization and how they changed it led to success. But pretending like you can be exactly like them will only end in failure. Find your own path that matches where you as an organization are and identify the things you really</em> need to change. Find a way to change those things that will work with your team and your organizations idiosyncrosies. Don't be a cargo cult. Be an expert in your organization and it's challenges.</p>

Thoughts on Engineering Management after 7 years

Unknown — Sun, 11 Jun 2023 00:00:00 +0000

I've just recently begun a new job. For 7 years I've been doing some form or or another of engineering management at GoHealth, Inc. There were definitely things that I appreciated about being a manager. Mentoring other engineers has been one of the more rewarding things I've ever done in my career. But being a manager is exhausting work. It's emotionally and mentally exhausting. I'm ready to take a break from it all for at least a bit. I don 't know for sure that I'll never do it again but I do know that I need to not be doing it for a while so I can rest.</p>
I do want to take some time to write down what I've learned being a manager as I leave it behind. Some of what I learned is just general management learnings. But some of it is more germaine to being an engineering leader specifically. The following is a list of my collected notes over 7 years of being a manager of software engineering teams. I've broken them up into General management lessons and Engineering management lessons.</p>
General</h2>

Peer review is an important signal in employee reviews.

An employee's peers have more on the ground knowledge of how someone is doing on the team.</li>
As a manager we have context on how their contributions contribute to the company's goals.</li> </ul> </li>
It is easier to break culture than it is to fix culture.</li>
Your decisions as a manager have a wide blast radius.

You need to have a light touch.</li> </ul> </li>
Collaborative Working sessions are a useful forcing function.

But asynchronous effort is often more efficient.</li> </ul> </li>
Matrix organizations have a higher communication burden. Lines of communication are mutating and fuzzy.</li>
Part of managing up is not hiding problems.

Sometimes you have to let things fail to ensure that problems get addressed.</li> </ul> </li>
Part of managing down is owning and apologizing for mistakes.

Good employees will forgive and respect you for owning your mistakes.</li>
Bad employees will be impossible to please. You will have to manage them out.</li> </ul> </li> </ul>
Engineering</h2>

Documentation is just as important as Code. Make sure you prioritize it.

Doctests help to ensure code documentation is up to date.</li>
documentation that is versioned with the code is better than a wiki</li>
generating and publishing docs from a repo as part of a ci/cd pipeline is preferred.</li> </ul> </li>
Automated Testing is better than Manual every time.</li>
Scrum/Agile or other methodologies are a defensive workaround not a solution.

if you can fix the core problem then you won't need the methodology.</li>
Process can't fix the problem of too much process.</li> </ul> </li>
CI/CD get's progressively harder to implement the more software you have written.

You are better off starting out with it in place or very early on.</li> </ul> </li>
All else being equal having a smaller set of supported technologies is an organizational super power.

It's important to choose a set that actually fits your needs.</li> </ul> </li>
Zero Trust is hard if you didn't design for it in the beginning.</li>
During an outage it's not uncommon for people to be experiencing multiple different problems.

Make sure your team is categorizing each type of issue so you can distinguish between them.</li>
Look for the systemic problem not the individual surface problems.</li> </ul> </li>
If you have hired and run planning in a particular way for a long time then any dramatic change needs to be planned and communicated well ahead of time.

Make sure to include timelines and milestone in your communication.</li>
Be aware that you are probably violating some sort of social contract with your people when you do so.</li>
Expect emotions and departures in some cases.</li> </ul> </li> </ul>

How Dare You

Unknown — Sat, 09 Jan 2021 00:00:00 +0000

Be aware the following is a rant. It is not carefully researched, nor is it a methodical analysis or logical argument. It is instead an attempt to capture my feelings after the events of Jan 07, 2021.</p>
I'm really angry</h1>
I'm angry. Not just a little angry, I'm furious. Angry enough that I want to punch something. For context, I am a Christian. There are times in my life that I would have been considered a conservative politically, at least in some dimensions anyway. But I do not recognize evangelical conservatism today.</p>
The recent events at the capitol are the perfect culmination of 4+ years of Trump politics. But that isn't really the source of my anger. The source of my anger is illustrated by the flags with Jesus on them at the assault on the Capitol. I'm angry with every prominent evangelical who aligned with and supported Trump. To borrow some phrasing from Christ. "Depart from me I do not know you." In the name of some policy wins you supported a fool. You made excuses for him. You encouraged him. You praised him. You told the people that it was Okay to follow Trump, and they did</em>. They followed him as he bullied others. They followed him as he ridiculed and belittled women. The followed him as he treated veterans shamefully. They followed him as he called foreigners names. They followed him as he lied. They followed him as he tried over and over to do more than the powers of the President allows him to. They followed him as he demonstrated incompetence over and over and over again. They followed him as he downplayed the pandemic. They followed him as he falsely claimed success over it. They followed him as he contributed to the deaths of 300,000+ Americans.</p>
As they followed him they got more and more angry. They believed more and more lies. They were sucked into conspiracy theories. Families were ripped apart. Friends, brothers, sisters, wives, and husbands watched in growing horror as their loved ones were entangled into a web of lies and lost their grip on reality. And as it continued you kept giving his followers permission to align with Trump. You dragged God's name through the mud for Israel and some court seats.</p>
I don't want to be you when God asks you to justify yourselves. You are responsible as shepherds for your flock. And you are a part of the reason there were flags with Jesus name being waved on national television as those people you led stormed the Capitol building.</p>
Shame</strong> on you! And may God have mercy on you when you face him.</p>

Perception is Sticky

Unknown — Sun, 19 Jul 2020 00:00:00 +0000

Perception can make or break your culture</h1>
Perception</strong>:</p>

a mental image; quick, acute, and intuitive cognition; capacity for comprehension; Merriam-Webster</a></p> </blockquote>
Perception is our word for how people experience and comprehend the world around them. When you are in leadership, understanding how people perceive their workplace environment informs how you guide them. Managing that perception will in part determine how effective you are as a manager. Perception forms from experience. Our historical experience built our intuitions about current experience. Managing how that historical experience impacts perception of current events is a part of leadership.</p>
Perception is sticky</h2>
Perception tends to be sticky. It's formed by historical context and experience and it is preserved by our tendency toward confirmation bias</a>. Once we have a particular perception we tend to notice facts and events that support that perception and discount the ones that don't. As a result, when a negative perception forms in someone it can be particularly challenging to dislodge it. Every misstep, every event or action that supports the perception is magnified and held up as an indication that nothing has really changed. While every attempt to address the problems and improve is forgotten or thought to be of little importance.</p>
It's in our best interest as managers to avoid allowing a negative perception to take hold. Once they do, you may never be able to dislodge them. It's very hard to recover from the formation of a negative perception. It will color the culture and will poison the intuitions of your employees until it is changed.</p>
Perception is communicable</h2>
When we encounter a new situation, such as a new job, we look to those around us to help develop our intuitions about what to expect. We don't have the experience to inform our intuitions yet, so we rely on the experience of others. If the prevalent perception of everyone is negative then we'll gravitate toward a negative perception as well.</p>
Once we begin to drift that way, then our confirmation bias kicks in and helps to push us even further in that direction. It takes a lot of effort to go against that cultural drift once it starts. Both the sticky and communicable natures of perception serve to make it one of the things that can make or break a culture. Unfortunately, there is only about a 50/50 chance that you'll be starting with positive perception from the beginning. Chances are you'll be starting out with a handicap.</p>
Perception is rarely a reflection of reality</h2>
Our perception is affected by a lot of internal factors. We are quite good at rationalizing our own beliefs and justifying them. We also aren't usually in possession of a full understanding of everything we experience. Our perception is colored as a result. Both negative and positive perceptions tend to be somewhat misinformed. A negative perception will usually blow things out of proportion. It will paint things in an overly negative light and discount the positive aspects of a situation. A positive perception will downplay certain events and rationalize others.</p>
Perception can create worry where it's not warranted or it can create unrealistic hope. It colors our reality in ways that can prevent rational and realistic expectations. The more out of line with reality a perception is the more incorrect the reactions to events will be.</p>
Great leaders shift perceptions</h1>
Great leaders demonstrate a capacity to manage the perceptions and the intuitions of those they lead. In a sense managing perception is about causing a paradigm shift in how people approach their situation. Sometimes the shift is big and sometimes it is small. I think the best leaders work to shift perception in ways that better match reality. A perception that is closer in line with reality leads to better outcomes. It reduces blind spots and allows an organization to react appropriately to its environment.</p>
Acknowledging the historical context</h2>
You can't shift perception without first acknowledging why the current one formed. The first step to correcting bad perception is to acknowledge that it exists for a reason. If the perception is lingering after a previous bad reality then before you can show that the reality has changed you have to acknowledge the bad reality that came before. If the perception is caused by poor communication of reality then acknowledging that failure is the first step to correcting it.</p>
Shifting someone's perception is much harder if you try to pretend the perception doesn't exist. You have to confront the perception and acknowledge the causes to generate enough of a shock to begin moving them in another direction.</p>
Highlighting additional context</h2>
After acknowledging the cause of incorrect perceptions, you need to work to counteract our confirmation bias. Highlighting the context that gets ignored. Emphasizing the importance of context that gets downplayed. This gradually begins to shift perception. There is no shortcut here. It takes consistency and time. You won't shift perception overnight. But if you stay consistent and honest, eventually perception will be more in line with reality.</p>
Recognizing their own perception</h2>
Great leaders recognize they also have perceptions that can be just as sticky as the people they lead. If the problem is that your perception is out of line with reality, then you won't be able to work to keep others perception in line with reality. We have just as much of a tendency toward confirmation bias, and we need to work just as hard to counteract it. Sometimes, when the perceptions of those you lead differ from yours it's because you are the one who needs an adjustment.</p>

Intermediating during change

Unknown — Sat, 23 May 2020 00:00:00 +0000

Managing change</h1>
A significant portion of my job these days is to act as an intermediator during change.</p>

intermediate: verb (used without object)</p>

to act as an intermediary; intervene; mediate. Dictionary.com</a></li> </ol> </blockquote>
I stand between upper management and the teams that report to me. I mediate the interaction between them. My role is one of translator, shield, and understand-er in chief. I am the primary way that my direct reports understand the goals, needs, and requirements of the company they work for. I'm also the way that the company understands the mood, needs, and capabilities of the people they have employed. This is, to say the least, the most exhausting and yet in some ways most fulfilling part of my job.</p>
If you work somewhere for long enough eventually you'll see a negative narrative start to form. A policy change will strike people the wrong way. A technology choice will be made that others disagree with. The triggering event could be anything. But the effect will be somewhat predictable. Confusion, feeling they are ignored, anger, resentment, all might start manifesting in your team. If you let those feelings stay there then they'll fester and before long you'll have a team of negative attitudes on your hands. As a manager you can be reactive to these events and find yourself playing catch up continually or you can be proactive and manage the impact that these decisions will have on your team.</p>
Planned Change</h2>
Your goal in managing change is to be proactive. If a change is coming to my team and I've been made aware of it I need to take some steps to ensure the health of my team as the change is happening. My first task is to understand the change and what is motivating it. What is behind the change? Why does the company find it necessary. What will be the impact on my team of this change. I need to be empathetic to both the company and my team. Most change is motivated by something but those motivations aren't always clearly communicated. My job is to understand those motivations so that I can clearly explain them to the team. No one likes change for no clear gain. But most people can get behind a change with clear reasons behind them.</p>
My next task is to understand the impact this will have on my team. What questions are they likely to have? Will there be undesirable impacts that management may be unaware of? If you can anticipate those questions or potential setbacks you will go a long way to easing everyone's minds. It's crucial that management knows you understand the impacts these changes will have on the team and can communicate them back to them. It's also important that your team knows you are already proactively managing that impact on them. If the change is going to slow them down and you've already let management know to expect that then your team is going be less anxious about that change affecting their standing at the company.</p>
Once I understand the change that's coming, it's motivation, and it's impacts then I can communicate it to my team. My goals are to help the team understand the change and prepare for it mentally and emotionally. To do this I'm upfront about the costs the change will incur. I make sure that they know I've already communicated those costs to the people and if possible I detail how I've negotiated ways to mitigate or handle those costs. I also make sure I listen. Just because I've done my homework first and tried to anticipate all the impacts doesn't mean there isn't something I missed or was unaware of. If I learn anything new from the team then I commit to communicate it to leadership. Both the team and the company leadership need to know that I am an effective translator, and they can trust me to accurately represent their needs to each other.</p>
Sudden change</h2>
Sometimes change comes suddenly. Sometimes the environment for the company changes so fast no one sees it coming until it's right on top of them. Maybe communication lines break down in a place outside my control. Perhaps I just drop the ball. When that happens first I have to accept it and then I need to follow the same playbook but on an accelerated timeline. I might have to tell the team that I'm working to understand the change same as them and then commit to follow up with them when I learn more. If I've done my job before this then I'll have earned enough trust for myself and the company that they'll wait for that feedback and withhold judgement. The company will be able to trust me to manage the team's response to unexpected change as well which reduces stress for everyone involved.</p>
Change is necessary</h1>
Change is a necessary part of growth at a company. It doesn't have to be negative but if the change isn't properly managed and communicated then by default that change will tend to produce negative attitudes. As an intermediator being empathetic and understanding how that change will impact both sides will go a long way toward change producing positive outcomes instead of bad ones.</p>

Remote Managing Software Engineers

Unknown — Tue, 19 May 2020 00:00:00 +0000

I'm a Remote Manager now</h1>
If engineering management is hard try doing it remotely</strong></p>
I'm one of those people who enjoys working from home. I'm just introverted enough and have enough focus that working from home is kind of my ideal state. I'm also a manager now though and that adds a whole dimension to working from home compared to being an engineer. It's no longer about your effectiveness when working from home. It's also about how effective your team is in a remote situation.</p>
In this Covid19 world we find ourselves in, many software shops have found themselves suddenly transitioned into a full remote working environment. This poses new challenges.</p>
Good remote management is just good management</strong></p>
Many of the things that make for good remote management of software engineers are also just good management practices. You need to empower your engineers to make decisions autonomously. You need to be able to trust your engineers and you need them to be able to trust you. You need regular communication with the engineers in order to facilitate all of the above. These same principles that make a remote team successful also make all engineering teams successful. Mastering them when you are remote managing will only make you more successful when you are local.</p>
Principles of Remote Management</h1> Remote management works best when you have given your team a clear mental framework for decision making and autonomy. You can't be as available for that quick clarification or to obtain immediate permission. You need your team to have the tools required for autonomy in their decision making. In my previous article</a> article I mention how important narrative and identity are in engineering management. When managing remotely, It's crucial. They can't just stop by your desk to ask a question. You won't overhear conversations at desks when you walk by, and neither will your team members. Many of the tools you used to promote a team identity and culture are harder when you are remote.</p>
Written communication</h2>
Written communication can go a long way to giving your team a reference for decision making. Keep a blog or send out weekly and monthly memos with your perspective on the state of the team. If there are policies or processes that are required for the team to follow, make sure they are clearly documented and easy to find. When the team meets in a video conference make sure that someone is keeping notes that can be disseminated after the meeting. It helps keep those who had audio issues or weren't able to make it keep in sync on the decisions. This all helps the team to understand how you see the teams identity and the narrative you wish to craft.</p>
Written communication helps keep the mental framework the team uses for decision making stable. If there are disagreements among team members then documented policies and processes give them a way to resolve the disagreement quickly by referring to that documentation.</p>
Consistency</h2>
Being remote magnifies inconsistencies in your communication. You have to be consistent in how you apply the principles that define your teams identity. If you change how you make decisions every week then it's difficult for your team to learn how to make decisions on their own. They'll continually be referring decisions to you and you'll find yourself micromanaging. Micromanaging a team is nearly impossible to do when working remotely.</p>
Give your engineers a way to reliably make decisions that won't surprise you or other team members. If they have a consistently communicated framework for decision making then they will be able to make decision without fear and the need for your involvement will be reduced.</p>
Be virtually present</h2>
Lack of a physical presence is a barrier that must be overcome. You need to find ways to be available to your team through as many virtual mechanisms as you have. Management tends to be more interrupt driven than software development is. Have virtual office hours. Hold training sessions over Video Conference. Pair with team members over Video and a shared screen. Whatever you do don't miss your one on ones with the people you manage. It will take time for them to build that mental framework for autonomous decision making and there are no shortcuts. Make sure your team can access you when they need it.</p>
Build Trust</h2>
The foundation of an effective remote team is trust. It is much harder to build trust without a physical presence. A lot of trust gets initially built via non-verbal communication like body language. You will have to work harder to build that trust when remote. The above points about regular consistent communication are critical to your ability to build trust.</p>
Demonstrate follow through in what you commit to do. Don't promise something you can't deliver and be frank about it when you mess up. Honesty is key to success. When the team learns they can trust your word they will get more comfortable.</p>
This forms a feedback loop with their autonomous decision making. When they feel like they can trust the foundation they'll walk more confidently and make better more consistent decisions. That in turn will cause you to trust them more as well. Clear consitent communication leads to consistent decision making which leads to more trust in both directions.</p>
Final thoughts</h1>
If your reading this and thinking "This is just good managment in general", then you are absolutely right. Most of what makes a good manager is also what makes someone a good remote manager. The only real difference is that any failures in these principles is magnified when you are remote. But if you can excel at it then some of the benefits can be incredible. Engineers who are remote get more deep focus time than in the typical open plan office you have today. If you can nail the team identity and narrative and keep everyone on the same page then productivity on your team might just skyrocket.</p>

Engineering Management is Hard

Unknown — Sun, 19 Apr 2020 00:00:00 +0000

Learning to be a manager</h1>
Some time ago I took on a Management role at work. This is a role that, seven ago, I swore I never wanted, but life experience has a way of changing how you feel about certain things. Before joining this company I experienced one of the most incompetent engineering managers I've ever worked with. I've had some sub-par experiences but never true incompetence. I realized that I needed a better understanding of what an engineering manager should do. I needed some survival skills and the best way to do that is to learn by doing. If I got a chance to experience some of that in future roles I decided I would take the opportunity. So here I am with a role that is 80% managment and 20% technical contribution. In theory I think it was intended to be 50/50 but reality differs quite a bit.</p>
Engineering Management is hard</em></strong></p>
I don't think I realized just how hard managing people is until I experienced it for myself. Some of the problems are fundamentally unsolvable. The most you can hope for is to mitigate the fallout. You can't just hack your way around people problems and management has a considerable amount of people problems to solve. I've been learning a lot in my on-the-job training experiment, and I'd like to talk about what I've learned.</p>
Communication</h1>
You are a conduit between the business and the engineering team</strong></p>
In many ways being an engineering manager is about being a translator. You are a conduit between the needs of the business and the capabilities of the engineering team. Walking a fine line between what the business needs to stay in business and what it takes to create scalable technology is not an easy task. You have to tell both sides no sometimes. I've learned that honesty, transparency, and tact are the among the most important attributes of a good manager.</p>
Honesty</h2>
It's important not to promise what you can't deliver for either side. Don't lie to your engineers about when and how you'll be able to tackle technical debt. Don't promise procedural changes that you can't realistically deliver. Be honest about what you are empowered to accomplish. Be realistic about the capabilities of the team to the business. Don't oversell and don't undersell. If you lose the trust of either side you'll be ineffective in your role.</p>
People appreciate it when you are honest about your failings</strong></p>
Come clean when you mess up. You aren't any more perfect than the next guy. Sometimes you'll drop something on the floor. When it happens acknowledge your mistake and work to address it. People appreciate when you are honest about your failings and diligent in addressing them. It gives them faith that you will be honest with them and they can trust you.</p>
Being transparent when you can and being forthright about when you can't be transparent are important. Everyone like to understand the reason for decisions they don't like. If they are able to put those decisions in context it goes a long way toward calming them and helps them to see whether there is a light at the end of the tunnel. They understand that you can't always share everything with them but they appreciate when you are honest about that handicap.</p>
Tact</h2>
Being honest doesn't imply you need to be harsh. It's possible to deliver the truth without triggering an unnecessarily negative emotional response. Your goal should be to ensure that any emotional response is derived from the factual content of your communication and not the method of delivery. This can be harder than it sounds. Trying to eliminate any emotion from your delivery can be just as bad as including negative emotion.</p>
I have found that focusing on empathy is helpful</strong></p>
I have found that focusing on empathy is helpful. Try to understand how your audience is going to percieve the news you need to deliver. It goes a long way when it's clear that you understand the impact what you have to say. Empathy can inform which type of emotion you should inject in your delivery.</p>
Be sure to listen as well. In many ways listening does as much as to give people an impression of tact as your delivery does. Follow up your delivery with an opportunity to listen and see how it was recieved.</p>
Team Culture</h1>
By default culture flows from the top down, and for any team you manage, you are the source of that flow. You have an outsized impact on your teams culture. If you are negative then your team will tend to be negative. If you are positive then your team will tend to be positive. I've been thinking a lot lately about what you can do to create a good team culture.</p>
Identity</h2>
Identity forms an outsized part of your teams culture. What do you need your teams engineering identity to be? Should you be a quality at all costs team or are a ship it and fix it if it breaks in prod kind of team? Should you value unit testing or do you get more value from Manual QA? Is CI/CD in your DNA or are weekly planned deployments better? What about developer tooling? Is it everyone for themselves or is tooling a first class part of your teams identity. In your technology choices do you tend toward build or buy?</p>
Your goal is to be in a position where you don't need to micro-manage</strong></p>
To be effective you need to be clear about your teams identity. This will give guide rails for your developers and team members. They will know what mental framework they should use when making decisions, it frees you from having to be involved in the minutia. Your goal is to be in a position where you don't need to micro-manage.</p>
Narrative</h2>
As a manager you need to provide a narrative to your team that is positive, believable, consistent, and evolving.</p>
You don't want a narrartive that is framed as us vs them, something I've seen before in engineering organizations. You want it to focus on how the team can be productive and make the business successful.</p>
If you aren't honest then the cracks will start to show</strong></p>
A good narrative is believable, one that everyone can buy into. Telling a story about where the company is going and how the team will be able to contribute to that direction does wonders for team cohesion. Make sure that the story is accurate and not a fabrication. If you aren't honest then the cracks will start to show and people will share their own narratives. Narratives that, in many cases, lead to bad places for the team.</p>
If parts of your narrative are in conflict then the team won't know how to be self directed</strong></p>
An inconsistent narrative will kill productivity. If parts of your narrative are in conflict then the team won't know how to be self directed. They'll be backtracking all the time and it will appear to them that the ground is shifting under their feet. If you craft a good narrative then the team will have a shared story. They will know where they fit.</p>
Acknowledge that the environment is changing and the team needs to adapt to it</strong></p>
Narratives need to change and evolve. When this happens, be transparent about it. Acknowledge that the environment is changing and the team needs to adapt to it. Acknowledge when something isn't working for whatever reason and get consensus on how to change it. Don't try to shoehorn the changes into the old narrative.</p>
Potential Impact</h1>
If the above challenges appeal to you then you might be interested in some managerial roles. The impact you can have on a team and a company make it worth it. You can be the difference between a good work environment for employees and a bad one. You have the potential to remove barriers to productivity for a team if you do it well. If you do it poorly though, you could be the reason a team's productivity stalls. The risk/reward here is considerably different than any other role I've had.</p>

On Inertia

Unknown — Wed, 21 May 2014 00:00:00 +0000

This is my last week at Google.</h1>
Friday will be my last day. Which feels very strange I must admit. I'm a high inertia person. I tend to stay the course once I've picked one which is probably why I've been at Google for 6 years now. But now that is all changing so this is as a good a time as any to look back.</p>
Google is without a doubt the best company I've worked for to date. It's a deeply engineering centric company which has many benefits. They invest heavily in engineering tooling and engineering culture. Everything from build tools to source control has had significant resources poured into them at Google and it shows.</p>
But by far the best feature of Google as a company has nothing to do with the engineering culture. Googles best feature is it's conscience. Without a doubt Google is the most moral company I have ever worked for. It's the kind of thing that is hard to verify from the outside but from the inside it's obvious that Google has a significant conscience in it's employees and it listens to that conscience and changes course as a result.</p>

Marzhill Musings

Coding Agents on Teams

Coding Agents on Teams</h1>

Cultural Christians, Aren't

Picking and Choosing</h3> Without the inherent intrinsic motivation of the christian faith then the temptation to pick and choose from the moral precepts and cultural norms will inescapble. You won't have a strong foundation to motivate what you keep vs what you leave out.</p>

Organizational Change

Thoughts on Engineering Management after 7 years

How Dare You

Perception is Sticky

Intermediating during change

Managing change</h1> A significant portion of my job these days is to act as an intermediator during change.</p>

Remote Managing Software Engineers

Engineering Management is Hard

On Inertia

Picking and Choosing</h3>
Without the inherent intrinsic motivation of the christian faith then the temptation to pick and choose from the moral precepts and cultural norms will inescapble. You won't have a strong foundation to motivate what you keep vs what you leave out.</p>