Why we are moving to microservices

Ever since I joined Twiga, there has been talk of switching to a microservice architecture. This idea had been baked into the product from the beginning so the switch should not be as hard.

I don’t actively code so there is no technical satisfaction but am still excited about what is coming next.

In this entry, will be talking about what I foresee coming.

The project becomes more expressive

In a previous entry, we delved into what it means to properly name entities in your code.

Having a big vocabulary is useful because we are better able to attend to concepts we have a name for.

By breaking up our system into microservices, we are able to have multiple entities to talk about. For example, it will be possible to have a meeting to discuss authentication and have its code cast in the background that is functionally separate from the rest of the system.

This tallies well with our brain which is wired up for affordance. Briefly described, the theory of affordance states we don’t see things as they are but as what they mean to us. Eg a cup as something to reach towards. Thus our code will now express meaning.

Evolution on multiple timelines becomes possible

Working for a fast growing startup has turned out to require far more versatility than I originally thought. The core product needs to serve multiple parties each having their own goals, values and tech readiness.

We could always work out what would be the best processes for the organization and then code it but of what value would that be to the person using it?

To ensure the product we deliver actually has value to a human, we need to evolve the product to better serve them, when we have multiple classes of users with fundamentally different needs, we are in effect building out a suite of products.

Microservices should help this flow much easier by enabling us to evolve at the rate of the relevant party.

Easier to scale the team

As I briefly explained in the entry How managers cripple their best team members new team members are inherently destabilizing.

Yet a feature of a growing startup is an influx of new team members.

The switch then should enable us to set up independent teams to work on different services while preserving the integrity of existing high performing teams.

Furthermore, it’s now possible to use multiple languages across the system growing our hiring talent pool and enabling us to use the best language for any specific use case.

Do you use microservices in your own organization? Talk to me in the comment section below or on my twitter @jchex


What it means to be a leader in a software team

In my career in technology, I have had the chance to serve in several leadership roles, latest being Twiga foods. My first time, I assumed leadership, or as the organization referred to it, management involved defining what was good for the organization, breaking that up to tasks then delegating the tasks to individual developers.

Over time, I have come to realize this model of leadership is seriously flawed, not in the least because developers are very smart people, smarter than I am.

Even more important, by monopolizing the work of visioning, I simultaneously lost out on great ideas from others and demotivated them at the same time!

In this entry, we will be looking at what I see is the role of the leader in a software team.

Custodian of priority

All teams face a bombardment of new information every single day. In this blizzard, its very easy to get lost and like the proverbial hyena get split in half!

Your job is to make sense of this incoming mess of requests, messages and bug reports and in the light of your team goals, give them meaning.

Not all tasks are the same, by giving them context, the team can then decide which tasks will give them the greatest return on their time and energy investment.

This also means you guide them in reviewing old commitments to see if they still make sense.

Trawl for new useful information

Nassim Taleb in his classic book The black swan introduced the concept of the unknown unknowns.

A black swan is an event, positive or negative, that is deemed improbable yet causes massive consequences.

In software, this translates to unplanned work. As mentioned in How you pay for technical debt

Like matter and antimatter, in the presence of unplanned work, all planned work ignites with incandescent fury, incinerating everything around it

As the leader, you need to be constantly monitoring your environment for signs of this black swans. It may come in the form of changing business environment for your clients or even unresolved disputes in choices to be made.

Either way, bring them up to the team for discussion and resolution.

Ensure personal growth

Maybe I have been more lucky than others. All engineers I have worked with have been naturally curious autodidacts. Yet for those new in the field, they may have no idea what they need to know or the experiences they need to have to mature into senior roles.

Your work as a leader then is to appreciate raw talent and provide support for growth.

Peter Senge establishes Personal Mastery as one of the core disciplines. He defines it as:

Personal mastery is the discipline of continually clarifying and deepening our personal vision, of focusing our energies, of developing patience, and of seeing reality objectively.

This is very important to understand and practice yourself while encouraging it for others as well.

You see, the higher the skill level of those around you, the more peace of mind you experience. When you are knee deep in a project this is not the time to start wondering if your colleague will drop the ball.

Provide feedback to the team

All successful systems are so because they have someway of getting and acting on feedback from their environment.

This means even as the team is working on the next iteration, you must be mindful of how the last release is being used. What do the users think of it?

Even here, you must be careful the team does not develop a culture of aloofness and insensitivity to the message coming from the rest of the business.

Through this entire entry, you may have noted the leadership I talk about does not need any official designation to execute, yet it will provide a lot of value to your team.

How have you provided leadership to your team today? Talk to me in the comment section below or on my twitter @jchex


How managers cripple their best team members


If you have been in the development community long enough, you must have come across the concept of a 10X developer. This is a mythical programmer that can do ten times the work of another normal programmer in the same amount of time and with higher quality.

I say mythical because, in my opinion, only teams can perform at that level. Yet, there is no denying men and women of special ability do exist. Furthermore, they are the stuff upon which great teams are built.

Will and Ariel Durant put it as

If we knew our fellow men thoroughly we could select thirty per cent of them whose combined ability would equal that of all the rest.

Or to use one of our own heroes, Steve Jobs

A players hire A players, B players hire C players

With this factors in play, once every while, a star team forms that performs superbly well. This team is almost certainly composed of very capable individuals. Unfortunately, the teams tend not to be stable because once formed, other forces conspire to break them apart.

In this entry, we will be looking at how you can be unwittingly killing off your greatest asset, your team.

Assigning a team member to multiple teams

This is by far the most common practice I have seen. To be honest, I have done it to my team members as well.

The benefits are visible and alluring. To name a few:

  1. Some resources are very expensive and need to be shared. For example, a specialist in machine learning who we pay say 500k would not make economic sense to be housed only in a single team
  2. Knowledge of the expert gets to be shared across the entire organization
  3. They just get sh*t done!

Unfortunately, the costs are not visible.

The strange thing about the most capable people is they have the hardest time saying no. Deep within them is the craftsman integrity, if something is required of them, they will get it done. Over time they get more overworked as they shoulder the heavy burden imposed by their own competence. Being humans, some other members will loaf off tipping the dynamic into an even worse state. Eventually, you end up losing this overworked resource to another organization.

Shifting a team member across multiple functions

This kind of rotation is important for new team members who need to understand how the business works. It’s also very useful for those who need a change of role. With that said, moving employees haphazardly across the organization means they never have the gestation period necessary to properly settle into one team.

You see, we are social animals, whenever a new animal joins our pack, they immediately become the object of interest. We ask ourselves questions such as:

  1. Will they conform to how we work?
  2. What is their working style and will it affect us?
  3. How does their presence change the power dynamics?

Eventually, the team does accept the member and hopefully, they become productive.

Fail to allow for this time and you have an individual who feels they constantly have to combat the social challenges of being the newcomer instead of producing what you pay them to.

Not providing proper communication tools for remote members

I am a big fan of flexible and remote working arrangements. With that said, I still believe a team should meet often.

As referenced in problem with big teams

Peer pressure is far more effective than the concept of a boss and much more powerful

If the team members can not see each other, how will they get the time to develop the necessary social bonds for interdependence to take over?

A rule of thumb would be:

If any one team member can not make it to the physical meeting, the meeting should be conducted as if the entire team is remote

This means stop being stingy. Invest heavily in communication equipment. The payoff will definitely be worth it.

What do you do to protect team members? Talk to me in the comment section below or on my twitter @jchex