Questions I always carry in my backpocket


At some point in your career as a developer, you will come to a fork, you will need to decide whether to continue majorly on the technical path or go into management.

If you do choose to go into management, you will come to notice you very quickly lose touch with the finer details of software development. It gets very hard to remember all the vim key bindings when you rarely fire it up.

An even more insidious problem is the fact information more easily flows down the organization than up. To illustrate this point, imagine a scenario where you as the manager come across a problem, would you have some second thoughts at reaching out to the developer responsible and having them fix it? Let’s flip it over, if you are the developer, would you report issues especially ones you know you may be the cause of?

With time, you find yourself operating somewhere in the cloud out of register with the realities happening within your own team.

I have come to find questions, are a useful tool to bring you back.

In this entry, we will be looking at some of the questions I always keep in my back pocket when walking into any kind of meeting.

Would you mind telling me more about why this is true?

In his book The Discoverers, Daniel J. Boorstin writes:

The greatest enemy of knowledge is not ignorance, but the illusion of knowledge

As a technical manager, you will tend to confuse the familiarity you have with the product with a true understanding of how it works. Thus when a discussion is going on, you don’t bother to truly dig into what they are talking about.

By asking the question stated above, you are able to get more clarity on the problem. It works better if you compliment it with the question “Who else has some insights into this”. Then you are able to see even more viewpoints.

Have you considered this option?

Given my technical background, at times, I do have some contributions to make to the discussion. The problem is you may end up having an opinion which you have offered up for discussion being interpreted as a decision.

This is especially true for senior-level managers such as CTO.

To counter the effect, offer the contribution as a question. This seems to soften the need to comply. It points out that your ignorance maybe in knowing the answer or is it not even knowing the problem being tackled in the first place.

In this way, you support thoughtful disagreements that explore and weighs people’s opinions in proportion to their merit with the end result of the best idea winning.

Is this discussion more interesting than it is useful?

No one likes two-hour meetings. Yet it’s very possible to get into this spiral especially when having a discussion on which technology tool or process to use.

Like moths, developers will get attracted to questions related to newest and shiniest technologies.

This is inherently good, after all, if you are not willing to abandon your tools and pick up new ones, your career in technology is likely to be short-lived.

Still, you don’t want to waste more than is needed touching on the nitty-gritty. At one point you have to decide to park the issue or just make a decision and proceed on to the next item.

What is the cause of that?

As I mentioned in an earlier entry Why you should never give off the cuff estimates making instant decisions is not likely to end up well.

When an issue comes up and you immediately start looking for a solution, you risk missing out on possibilities for a deeper understanding of the problem.

For example, The email service failed yesterday so key managers did not get their morning brief. Why? Because we exceeded our service limit on mandrill and there was no credit card to bill. Why? Because we did not expect to send emails to so many people. Why? Because we did not expect the organization to scale to this size.

From the series above, you can see not only do you need to solve the current problem. But all other problems which may arise from your assumption your organization will not scale or even other key providers who you may need to upgrade to a premium account.

What kind of questions do you normally carry in your own back pocket? Talk to me in the comment section below or on my twitter @jchex


Growing commitment within the team

In any organization, you will find two types of people, those who work to be part of a mission, and those who work for a paycheck. Ideally, you want to skew your developers towards the former.

This can be challenging owing to the nature of work developers do. You wouldn’t be able to tell if your developer is seriously churning code or trolling people on Reddit. Especially, if you don’t have a technical background yourself.

Thankfully, you can bank on people wanting to be part of something greater than themselves. You can tap into this intrinsic motivation to get great results both for your organization and your team.

In this entry, I will be discussing what I have found to work in my own practice.

Jointly come up with stories

The idea requirements are out there to be gathered is a truly misleading one.

I believe the act of story writing is a creative one. Out there what you will find is a problematic situation, your job with your team is to interpret the situations as problems and come up with stories which can then solve these problems.

By being involved in this initial problem setting, your team is able to see the meaning to the work they do.

As Fred Brooks put it:

The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures

By allowing the whole team to participate in this process, you get creations which are in line with the complexities of the business.

Regularly reflect on purpose

Kieran Setiya in his article on How Schopenhauer’s thought can illuminate a midlife crisis starts with this phrase:

Having jumped the hurdles of the academic career track, I knew I was lucky to be a tenured professor of philosophy. Yet stepping back from the busyness of life, the rush of things to do, I found myself wondering, what now? I felt a sense of repetition and futility, of projects completed just to be replaced by more. I would finish this article, teach this class, and then I would do it all again. It was not that everything seemed worthless. Even at my lowest ebb, I didn’t feel there was no point in what I was doing. Yet somehow the succession of activities, each one rational in itself, fell short.

You don’t need to be approaching midlife to get this sense, write-commit-push-deploy can feel as grinding.

Your best developers joined your organization for why you do what you do. It is easy to assume this sense will always remain there after all the company has not changed right?

I would posit you need to regularly remind your people why they what they do. At iHub we built communities, it was always satisfying to see the uber successes in the industry trace their roots back to our organization. At Twiga, we are helping bring food security to the country. From this perspective, each commit matters that much more.

Identify and manage freeloaders

I came across this interesting video showing monkeys understand the concept of fairness


Unfortunately, in any team, there will be those who will be looking to do the least amount of work possible. Even if they never mention it, the other teammates notice and I assure you they don’t like it.

Ben Horowitz called it the law of crappy people:

For any title in an organization the talent in that level will eventually converge to the crappiest person with the title. Everyone at the lower level will naturally benchmark themselves against the crappiest person at the next level.

Present growth opportunities

If you did your interviews right, your people are smart motivated and ambitious. The last thing they want to feel is stuck. Paradoxically, your best devs will resist promotion to management. This is no excuse to give up on them. Instead, provide them with opportunities to grow within their interests.

This means actively monitoring what they are working on and scanning for new opportunities to challenge them even more.

How do you grow commitment within your own team? Talk to me in the comment section below or on my twitter @jchex


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