Project empathy – quick update

Not long ago I began writing code to remember what it was like to build things every day for users with the hope to build some empathy for my direct and indirect reports

After a few months of doing close to 30 minutes in the morning of daily coding I want to share what I have re-learned so far.

The temptation to deliver quickly is high, but maintaining a high quality standard requires patience, persistence and consistency.

I made an effort to write up a service canvas, detailed tickets explaining the work to my future self, used true and tried design patterns to keep the code maintainable, covered the code under test, and used sonar cloud to review my code for known vulnerabilities and other static analysis checks.

These and more are expected outputs of any software my teams write. Going through the steps and making an effort to understand the value provided has done wonders to create empathy for the challenges software engineers face daily.

Releasing code is more complex, there are vast options from multiple providers that can make it overwhelming at first, but new tooling like render.com made it simpler and provided a glimpse into a bright future for hosting options.

In short, we ask a lot of engineers and oftentimes, as leaders, we get too excited about the prospect of shipping fast, but we fail to realize that good engineering practices have tremendous value and take considerable time to go through.


First 90 day plan – AI sponsored post

The first 90 days of a new job are critical for success. In order to make the most of this time, it is important to have a plan. The following is a suggested plan for the first 90 days:

  1. Establish your goals and priorities. What do you hope to accomplish in your new role? What are your top priorities?
  2. Get oriented. Learn about the company, its culture, and its products or services. Talk to people in different departments and get their perspectives on what it’s like to work at the company.
  3. Develop relationships with key people in the organization . Who are the key players in your department and across the company? Build relationships with them by asking questions, seeking advice, and collaborating on projects whenever possible.”

– this small blog post was written by an AI from you.com via https://t.co/hJihfuex9D

habits quality

Keystone habits in action

What is a keystone habit

According to The Power of Habit author Charles Duhigg, when there is a habit change, it can set off a chain reaction that has the ability to change your self-image.

It sounds simple, powerful, and appealing, so I wanted to try it out for my team.

The quality problem

At the time, we had lots of conversations around the quality of our product.

We released every other week, and every time we released a new version, we found ourselves staying late to fix bugs and spending the first week just worrying about the following incident.

We quickly got overwhelmed with all the places we could begin enhancing and would get stuck in endless debates about value, effort, and priority against other work.

When we least expected it, the next release was already here, and we had not made any progress on making our situation any better.

Trying out a keystone habit

When it came to us, we needed to start somewhere that we all agreed on, was easy to get started, and that would unlock many other enhancements along the way.

We chose to get good at automated testing.

In theory, our quality would improve, our confidence in deployment would increase, and we all agreed that automated testing had a low barrier of entry for all teams involved.


It was surprisingly better than we expected. Here are a few items we unlocked.

Confidence in deployment — with increased automated tests, we stopped fearing deployments so much since we knew the code was under test.

Surfacing regressions quickly — since the tests run on every pull request, we quickly knew when regressions were introduced.

Lower reliance on QA teams — before our automated test suite, QA felt overwhelmed trying to test everything before every release.

After automated tests, QA could guide engineers on good testing practices and validate core use cases.

Maintainable code — to our surprise, automating unit tests drove us to write code in smaller, easy-to-test functions, with the resulting code being easier to understand, maintain, and enhance.

Enhanced product understanding — another side effect was the desire to understand better the different ways our code implementation could work, driving more conversations with our product counterparts to dig deeper around possible edge cases, business validations, and other business domain-specific items not initially apparent from the initial work descriptions.

What keystone habits will you introduce to your teams?

Life icons created by Flat Icons – Flaticon

strategy Time management

Working in multiple time zones

Recently, the subject of teams working across time zones has come up in three separate conversations, so it makes for an excellent topic to write about.

Here are a few guidelines I’ve seen applied successfully that will help work across time zones a bit easier on your team.

Default to public conversations in chat

Doing so allows the people to chime in, even when they are not the intended recipient. 

It also makes it easy to get caught up on what happened while you were out, including essential decisions or ongoing conversations.

By the way, on the subject of ongoing conversations, be explicit about leaving a buffer time for other time zones to participate in the discussion rather than closing the thread 🧵 as soon as you get consensus among the people in your time zone.

Question the need to have a meeting

Meetings are an essential aspect of our work, but questioning if you should meet becomes crucial with multiple time zones.

Here are some ways to move a meeting asynchronous

  • Status meetings turn into status updates to a dedicated chat or page.
  • Decision-making meetings turn into collaborative documents following RACI/DACI format.
  • Problem-solving meetings turn into collaborative documents following a problem-solving framework such as ADR (architecture design review)
  • Information sharing meetings can become a pre-recorded video shared repeatedly to the team or organization, with a dedicated communication space for discussion. 
  • Brainstorming sessions become a multi-step asynchronous process to generate ideas first, set success criteria second, and filter ideas through the last success criteria.

Record meetings

At some point, a meeting is inevitable. We thrive in social environments and engaging with each other; meetings are as close as we get to that experience while working remotely.

But working in different time zones makes it difficult to get everyone to participate.

To be inclusive of others and disseminate information accordingly, record the meeting and share the recording with those not in attendance.

Extra points if the meeting recording is shared in your public chat messages for even more exposure to the information 

Take notes during meetings

While recording a meeting is great, the content is usually not searchable.

This is where taking notes becomes more critical.

Doing so allows for the information to be searchable, easy to share and provides consumption options for those that prefer reading over audiovisuals.

Be inclusive of time zones

To include people working in different time zones than your own, try to find a time between the participants.

When finding an overlap isn’t possible, consider having the same meeting in multiple time zones.

Empower and trust

A big complaint of new organizations distributing work across many time zones is the wait times needed for decisions and discussions to move forward.

I already spoke about some asynchronous ways to get to a consensus and make decisions, but the easiest way to unstuck someone is to make sure they are empowered and trusted to make decisions.

To do so, we will need laid out processes and an evident sense of direction. 

When people know the goal, they can figure out their way within the existing constraints.

Time zone icons created by Freepik – Flaticon

contractors management

Working with contractors

Recently, we’re getting ready to engage with contractors to help us drive a major initiative forward.

Behind the scenes at work, here is a view that happens before contractors write any code.


It starts by figuring out what company you’ll be working with. 

Your company might already have a pre-vetted list of vendors, but we reached out internally for recommendations in our case. After meeting with a few representatives, we settled on a couple of companies we liked.

To decide on one of them, we created a weighted decision matrix. We rated both companies in pricing, availability, expertise, onboarding times, size, and a few other attributes essential to our decision-making criteria. 


It is time to make things official with a company in mind. 

On our end, we have legal counsel to help us draft the needed documents, but you can reach out to the vendor and ask them to send you the first draft instead.

You can expect two documents, a Master Service Agreement (MSA) and a Statement of Work (SOW).

Please think of the MSA as the contract allowing both companies to do business with each other, while the SOW will go into the specifics for each engagement you have with them.

As an example, the MSA could contain non-compete, non-solicitation, or security requirements applying to all contractors. On the other hand, the SOW will have working hours, deliverables, pay rates, and additional job-specific information.

It is common to have one MSA and one or more SOWs.

Selecting contractors

With all the legalities in place, it is time to start figuring out who’ll be doing work for you.

Whether it is a long-term engagement or work with a well-defined deliverable, you will need to determine the technology stack and the level of experience expected.

The vendor typically does some initial candidate vetting and will present a few options for you to select from.

It is on you to further develop a process to validate that candidates meet your expectations.

That means a quick engineering assignment that we then review internally.

Product engagement

With a team ready, they’ll need to know what they will be working on. This is where your product manager comes in.

Just like your team needs guidance on the product and an understanding of priorities, so will your contractors.

Engineering engagement

With good direction, your contractors will now be ready to start work, so we’ll need to get deeper into specifics.

Think about items such as level of access to your repositories, reviewing pull requests, CI/CD checks, release strategies, getting the code working locally.

In reality, this part doesn’t look much different from the engineering onboarding your employees might go through.


Engaging with contractors is an excellent way to augment your workforce and make further progress on your initiatives.

But to ensure a successful engagement, it helps to:

  • have a procurement process to land on a suitable partner
  • understand the standard legal contracts used
  • have a way to examine engineers for your required expertise
  • please provide them with the necessary support to seamlessly work on what is important to you.

Contractor icons created by juicy_fish – Flaticon

habits stories Time management

Unblocking yourself

I am recovering from a couple of weeks of COVID madness and trying to get back into my habits, including writing.

To my surprise, I had no idea what to write about. I was effectively blocked.

Thinking about being blocked reminded me of being blocked at work and what I did to get moving.

In management, you are constantly bombarded with information streams that seem equally important.

To tackle the work, we resort to prioritization frameworks, to-do lists, four Ds (do, delete, delegate, delay), and other techniques that give us confidence that we’re working on precious work.

In my experience, prioritizing is where I tend to feel blocked, and the anxiety of not making progress kicks in.

This is where a quick mind hack kicks in to save the day. I add a to-do item called “prioritize work” and mark it as the most essential item on my list.

And just like that, I am now going through all the various items and applying prioritization techniques to ensure I use my time well.

The problem was not seeing the value of prioritizing.

I felt blocked just staring at the amount of work in front of me, and since I feel good about making progress constantly, I incorrectly assumed that prioritizing work wasn’t progress.

Unlock icons created by Smashicons – Flaticon

empathy management stories

Project empathy — day five – logic and the first test

Today felt productive, engaging, and like I finally made real progress.

Here is how the day went.

I created a new ProjectManager class to contain the logic for the project domain.

Since I am exposing the most straightforward functionality, I only added create and read methods, with creation only having a title as a required field.

Since I added new logic, I felt it pertinent to cover the logic under tests.

Luckily, the framework took care of a lot of the initialization items needed to test, such as 

  • In-memory DB
  • Seeding test data
  • Faking auths as various users
  • Dependency injection
  • Testing frameworks such as xunit and shouldly.
  • Sample tests to get you started

I can only imagine the amount of time it would have taken to set everything up to a point necessary to run a test.

With that note, I remember when I was getting started, I found the time required to set up tests quite challenging, especially when thinking about all the feature work I could be working on.

The learning here is that it isn’t enough to expect tests to be done. We need to dig deeper and embed within our teams the importance and value-added of having quality software.

Until next time.

Icons made by Freepik from www.flaticon.com

empathy management stories Uncategorized

Project empathy, day four — first new code

Day four was fun but short.

I began by setting my Pomodoro timer to 25 minutes to work on the first milestone, creating and viewing projects.

The project’s definition already has a lot of functionality, so I constrained the milestone only to include the title as part of the project.

The framework I am using https://aspnetboilerplate.com is highly opinionated, so I had to spend my first Pomodoro timer just browsing through the docs in order to get acquainted with it.

For my second Pomodoro, I wrote our first class, the project class. I added the database migrations and pushed them to the database.

I mentioned that the framework I am using is highly opinionated. It uses domain-driven design, so our class has no logic and can only be instantiated via a create method, ensuring that domain rules are applied consistently.

The logic will be added to another class they call “the manager” you can see more details on their design here.

So far, this little project has proven successful in building empathy. I had already forgotten that there is a significant amount of time devoted to research and learning for every line of code.

empathy management stories

Project empathy, day three — milestones

Day 3 took me towards project management; here is what happened.

I managed to get 30 minutes in before the end of my day, so I was determined to make the most out of them.

Recently, someone shared an article on project management and the importance of setting milestones rather than features.

Using the concept on our project means that I’ll work on delivering a subset of the functionality rather than a full feature.

So I created a milestone in GitHub and got started on it.

I spend most of the time thinking about what the milestone should contain and how to break up the work.

During the last two minutes of the Pomodoro timer, I created a branch in source control.

I am hopeful that next time I’ll be able to get started on actual code 👨‍💻

empathy growth habits management

Project empathy, day two

For day two of our project, I only got in 30 minutes of work. Here is how that went.

Since I am in management, I am constantly in project management and productivity software such as Jira and Todoist.

The idea is to build a project management tool that feels as simple as todoist.

Doing so should get me into design, architecture, and software system implementation.

Thus reminding myself of what it is like to do all the things I expect of engineers in my teams.

With this in mind, I created a few documentation tasks and got started on the first one, defining a `project.`

The deliverable requires a model, commands, queries, events, API consumers, and dependencies.

Luckily, I found a microservices canvas that neatly organizes the areas I hoped to document.

I copied it into our repository and filled it out with `project` details. 

Check out the draft here https://github.com/toyiyo/todo/blob/issue-3-define-project/services%20canvas/project.adoc

For day two, I figured out what I wanted this project to shape and started a documentation task via a microservices canvas template.

Stay tuned for day three.