Creating a culture of accountability
The culture of accountability is essential to any professional engineering team. We discuss how to build and maintain the habit of accountability.
Hi, this is Peter with the next edition of the Professional Manager newsletter. I publish this newsletter to illustrate what decent, seasoned, professional engineering management could look like.
We previously explored that it is the responsibility of every engineering leader to understand how they are spending the most significant investment their company makes - people resources.
You do not have infinite resources!
You need to choose how you spend your company’s money wisely. Even when the company is well funded and the economy is crushing it, operating under the assumption of infinite resources is foolish. Focusing on one of the company’s most significant expenses, paying its employees, is an excellent start to exercising accountability.
Of course, there are other essential areas engineers and their leadership need to be frugal with:
Cloud operational expenses
Money spent on engineering tools
Customer acquisition cost
Cost of running APIs your business relies on
The list goes on, but we will only focus on the most significant expense you will have the most control over, which could be the hardest to understand, manage, and reign in.
How are you spending all that money we’re giving you?
Only when I served in more senior levels of management (Sr Director+) did my boss ever ask me how I spent the company’s money. To many of my bosses who managed me earlier in my career, I think this was a missed opportunity! You must be accountable for spending your employer’s money as a manager.
Nearly all CTOs and VPEs regularly have to answer how they use the money their company trusts them with. There are effective, pragmatic, sustainable ways to answer this question, while some will make you look like a micromanager chasing meaningless team metrics.
I require every leader in my organization to articulate how their teams added business value last week and how they intend to do so this week. I hold myself to the same standard! The more senior you are in an organization, the higher level these updates will be. The spirit of my mandate is that leaders understand how their teams contribute to the company's advancement. This understanding also helps recognize bottlenecks and patterns.
Weekly roll-ups
Depending on the organization's size, weekly rollups can take on different shapes. A casual conversation may suffice at a small company. Weekly operational kickoff meetings could work. I have seen a rolling diary published for offline consumption.
There are some best practices around rollups I highly recommend:
Architects/principals involved - these folks are also responsible for the business's success. They need to be part of the weekly readouts. They are senior leaders in your org, they are accountable for business results. Having them part of the weekly roll-up meeting will have its benefits.
Weekly frequency - anything more frequent, the meeting becomes a burden. Anything less frequent, you may lose out on the ability to quickly recognize wrong strategic directions.
Schedule for the start of the week - you will likely want to schedule the weekly roll-up meeting or make the due date of the weekly diary Monday or Friday. I strongly suggest you pick Mondays. We show up at work with newfound energy, ready to take on the week. Having the meeting or the due date on Fridays will mean that most will just want to plow through it, will not give the updates much thought, and will forget most of it by the start of the following week.
Focus on the right things - business value, incident reviews, First To Know dashboards, and staffing discussions are fair game for this meeting.
Public artifacts - artifacts the teams produce should be publicly available for consumption across the company.
Format not prescriptive - let the leaders of each team decide on the format they will utilize. Work together to develop the format that works for the given team and you. If you go against my advice and mandate a specific format that works for you, you better provide a linter so that organizations can easily comply with your formatting requests.
Regular demos
Regularly showcasing what the team built is good for the soul of an engineering organization. Regular demos allow everyone to celebrate the smallest of progress, stay in touch with the developing product, and understand the details. There are some tools in my toolbox around compelling demos.
Invite stakeholders - cast a wide net for optional attendees. Of course, the entire engineering team, product manager, and designer all need to attend the team’s demo. Adding executives, customer care leaders, and marketing colleagues to your demos is great. You will be surprised how much your product can impact the lives of your colleagues. Give them a chance to see the product before your customers see it.
Weekly frequency - any engineering team should be able to demonstrate progress over a week. “But Peter, my sprints are two weeks long, so I could not demo weekly” - you may retort. I will refer you to the first sentence under this bullet. I also invite you to figure out how to break up your stories into more consumable bits.
Live demos - it is helpful to show progress via live demos. It is okay for the code only to run locally. Your team will have the product deployed by next week and include it in next week’s demo. You also don’t want engineers wasting their time recording a video of the demo.
Celebrate imperfection - the weekly demo is intended for the circle of trust. Imperfections are expected for a live demo. That is exactly the point. Celebrate those imperfections!
Nerd out - encourage folks to open up the IDE and explain the gnarliest parts of their solutions. I’ve told stakeholders before that the customer-facing part of the demo concluded, and we were going to nerd out for the rest.
Babysteps - teams who haven’t developed the demo muscle will be intimidated by the desire to show weekly progress. Ensure them that the most minor bits of progress are all that you are after. In the early phases of a project, an API contract and a GraphQL schema, along with consent from the consuming teams, will be sufficient to demo.
With thoughtful weekly progress roll-ups and regular demos, you can quickly establish a culture of accountability for business value and progress. These two tools will help you better understand how you spend your company’s money.
Leonard the Scrum-Dictator
Leonard, the Scrum-Dictator, was the CTO of a 200+ engineering organization. I reported to Leonard as a Sr Director of Engineering. For the first year of Leonard’s tenure, he had a large budget. He did not exercise any restraint in the way he spent the company’s money. After year one, our ambitions were not materializing, the board started to get impatient with us, and Leonard, all of a sudden, was held accountable for how he had been spending the company’s money.
Instead of following my playbook above, Leonard rolled out a rigid, prescriptive, one-size-fits-all Scrum process. Leonard demanded that we all run Scrum, story point the same way and that all of our 200+ engineers march to his scrum-dictator drumbeat. This did not work for anyone. For example, my team ran a Kanban process, focusing on shipping to production as quickly as possible. Leonard’s scrum demands were devastating to my team. When I tried to push back, Leonard’s insisted he had to implement a uniform scrum process because “that was the only way he could explain to the CEO and to the board where all the money was getting allocated to.”
Even scrum-based teams hated Leonard’s process. They felt Leonard gave them no flexibility in making the process their own. We spent endless days arguing about story-pointing philosophies.
Leonard’s attempts to roll out his scrum process never bore fruit. He could never answer his boss’ questions about how he was spending the company’s money. Leonard’s time would have been far better spent using a process to learn about how his teams were delivering value and giving them autonomy with accountability.
Summary
This edition covered some of my techniques around introducing a culture of accountability to engineering organizations.
I sincerely thank you for reading my newsletter. I’m always open to your feedback. I would also love for you to share The Professional Manager with your friend!