Dion Almaer

Software, Development, Products

Archives for June 2015

Habit Driven Development

Leave a Comment


I have happened upon the importance of habits recently. I have always heard “good habits are important”, but I never really embraced that in a thoughtful way.

That changed when I had a health crisis. I realized that I needed to make a change to get healthy. I needed to create new habits with respect to nutrition, exercise, and holistic health (including mental health, sleep, you name it!).

I would often set myself lofty goals, and then if it didn’t look like I would reach them, everything would fizzle out. On the contrary if I can do something incremental on a daily basis it sticks, given enough repetitions to kick in.

Software Habits

A lot of the changes that we have seen in software development revolve around habits too.

Agile

I tend to dislike proprietary terminology or One True Way. There has been a backlash towards Agile ™ as many have seen it slip into dogma. As soon as you find that you have forgotten why you are doing something you are in trouble. The agile manifesto itself is a simple document that talks about values: favoring X over Y.

Some took this and created religion around them. There are fascinating spiritual questions, and long term values and learnings around how to live a good life. Certain folk managed to persuade people that their recipe is Truth whilst the thousands of other recipes are so wrong that you can end up in hell for believing them. Fortunately we don’t think that Scrum is an infallible document passed to man from God, so let’s keep trying new things and focusing on what works, what doesn’t, and why.

Athiests can also tend to poo poo particular practices. Some are bizarre and even barbaric, but others make sense. Alain de Botton lays out this case well in his book, Religion for Atheists.

Let’s not make the same mistake and ignore the good things that have come from various methodologies out there. Let’s not try to setup our own habits because we are scared to “be as bad as them”. Checklists don’t stiffle, they can save you from making mistakes, forgetting good knowledge, and give your brain the time and space to noodle on the important problems at hand. Dogma occurs when you forget why you are doing something and refuse to change with new knowledge and learnings. Practices that do change upon reflection, including looking at first principles, are a great thing.

Continous X

There are many tasks in development that we have managed to chunk up and allow us to do them more frequently. I am old enough to remember the bad days where people were scared to do a certain task because they couldn’t trust how it would go. At every release you would see people with crossed fingers, first for the release to get out well, and second to make sure that if a rollback was needed it actually worked. Today we release all the time and some are actually pulling off continuous deployments and ideally delivery.

We have seen the same thing elsewhere:

  • Writing and running tests
  • Creating and merging branches
  • Setting up infrastructure.

There is a huge pay off when you can trust your process. You can deliver higher quality product with less risk and a much improved pace over time to boot.

There are severe penalties for not catching things early. I remember the work at Palm where they found that: if you catch a bug on the same day it was introduced you can fix it in around an hour. If you catch that bug later it can take 24 times as long, and take a day. It is obvious why: your brain was right there so you don’t need to context shift, and the changes are few.

The core of an good process in my mind is simple:

  • What are the core values of the team
  • What practices map to those values
  • What habits will result in an improvement
  • Reflect and iterate.

A process that shows agility seeds the core values with the ability to change quickly because of the simple observation that those things that can’t evolve tend to die. This doesn’t mean that the process is fast. It may take effort to build agility into your software, but the bet is that it pays off and gives you the best chance of not getting stuck in the future.

The key to non-dogma is the retrospective. As long as you can revisit and try new things you can get to where you need. Just as with A/B testing, sometimes you can’t iterate to a better solution quick enough. Iteration is great if your dart was pretty close to the mark but sometimes you should throw another dart.

What are your and your teams habits? When was the last time you took a deep look at the why as well as the how?

Project Managers Are Underrated

Leave a Comment


I just overheard an engineer teasing a buddy about being a project manager.

“Work should be done in small teams. There is no need for a project manager if you get that right.”

I have often heard this, and I feel bad because it shows that many people haven’t experienced the liberation that an amazing project manager brings to a team.

I get understand why you may not have worked with one, as they are incredibly hard to find. They fall into the hot masseuse paradox.

A rather sexist older man once explain this problem:

“Everyone wants to get a massage from someone smoking hot of the gender they are attracted too. Have you noticed how hard they are to find? I have a theory: if you are hot, you have probably worked it out that you don’t need to do that job!”

He then went on to more detail of hands touching his sweaty hairy body, but let’s leave it there.

The analogy has many flaws, but bringing it back to roles such as project management, often if you have the skills to be a great project manager you could also be a great engineer.

Great project managers are problem solvers. The problems can revolve around implementation issues, but they also include social and organizational problems. Those can often be more nuanced and trickier. People are weird.

What do you need in a Project Manager?

The title Project Manager is awful isn’t it? You aren’t going to just focus on projects, and the manager piece gets people into trouble.

You have ever seen tension between some of the roles? Let’s say you have actors such as a product manager, engineering manager, and the project manager. Who is responsible for resourcing? If an effort isn’t working well who is handling what?

Let’s say that our organization has a functional hierarchy (people report to others who understand their function):

  • The product manager is responsible for business outcomes (e.g. how are we doing against KPIs vs. how is software product delivery going right now)
  • The engineering manager is responsible for the delivery of the engineers on an effort. Engineers actually report to them and thus they are also charged with growing the careers and craft of the engineers, which creates a different dynamic
  • The project manager is responsible for unblocking the team and making sure they are as productive as possible.

If issues pop up it is natural for there to be tension between some of the roles and it is incumbent for all actors to listen to each other and accept input, whilst also understanding who has the final responsibility.

With agile approaches and some pushing away from strict projects, some pushed for a new name for the role, including Scrum Master, which is even worse.

Not only is the term very proprietary, but I have seen many use it as a way to lose their way on what the job actually is.

Let me put it in a form that may be familiar to the certified scrum master. The following is an invalid user story:

“As a scrum master my only real job is to run the daily stand-ups with an iron fist so as I can feel like I am adding value”

Have you seen this before? These people stop interesting conversations because of some dogma on time. They keep things moving irregardless of the context. For the kicker, they don’t share what they are doing with the scrum (as they don’t do things).

You will sense a great project manager when it comes around to them and they talk about work product:

“Frank and Jill were blocked by a misconfigured firewall. I went over to ops and kept pushing until the issue was fixed. I personally verified that everything was working well before bringing it back to the team”

or:

“I heard that the authentication team was finishing a sprint that had a chance to the tokenization. I met with the team, helped document the changes and created a PR with changes needed on our side. The tests seem to be running but I would love another set of eyes.”

or:

“[insert team that we are dependent on] had some problems and had to change course. I sat down with them to make sure that we could accelerate the mock environment so we could at least keep working against an endpoint while waiting for something more real to integrate in the future. I am concerned against hitting mocks but we made sure that they were running their tests against these and I will update the teams when I see something becoming real.”

Anyone can run the scrum meeting. That isn’t your value. Unblocking the team is what matters.

One simple way to get a pulse on how good a project manager is, is to ask them team “if Lindsey wasn’t here, how would you feel?” The team will start to panic a bit if they are really good 😉

In silicon valley startup culture people often think like the person I overhead in the cafe, that we should just keep teams small and not bother with a PjM. That can work for awhile. I tend to over index on hiring the concrete do-ers (engineers to sling code, visual designers to paint pixels) and pushing them to wear other hats (not that I don’t think the other roles are vital, or that “any engineer can do the job of an expert in another field).

I have also seen there be a small percentage of project managers and having them spread too thin. I would rather dedicate a project manager to one complex problem vs. have them context switching and just running scrums for four different teams.

Helping the team run efficiently is important, and the Project Manager can act as a Switzerland between the various roles. If you have worked on larger efforts that transcend one small team though you see how a great project manager can be the glue, connecting the right people at the right time, and solving issues themselves where possible.

I raise a glass to the indispensable project managers that I have worked with over the years. To those who haven’t memorized dogma, but rather understand the why, and how the context of a particular team or problem requires divergence from the text book.

Others in the series:

Why we hired THIS woman to run engineering

Leave a Comment

Let’s build and share more boxes to stand on!

Upworthy are masters of the headline, but usually the headline misleads you to content that doesn’t live up to the fodder.

This time though, it was the other way around. The content was much better than the heading.

I should probably share the headline:

Why we hired a woman to run engineering

Diversity, especially within engineering and technology companies, is the talk of the town. Companies share transparancy reports on their progress, and the press reports on the diversity of the executives that speak at conferences.

It’s a big deal for a reason. It hasn’t been fair, and everyone benefits from a diverse work place.

What irked me about the headline though was that it hit my funny bone on how some look to hire based on solely one attribute.

If you tap through to the content you will see that Rachel Fenn was well qualified for the role. She wasn’t hired because she was a woman. She was hired because she was the best candidate for the job. Given where we are, her gender should be a definite pro, but isn’t the only item in question.

Everyone has a huge number of attributes that make them up, both natured and nurtured into the now. At a macro level it is appropriate to see where we are lacking and to setup incentives to counter balance. I think it is fantastic to see special efforts in diversity hiring, investing in training and out reach, and doing all that we can to create change.

I am also aware that, although you don’t want to hire something you think is poor at their job just to meet a requirement, is it true that we will know that we are doing better when you *do* have some of your weaker members of the team who come from different backgrounds. You have white males who are weaker members right now after all!

I heard someone say “I will only hire women from now on”. On the one hand this will work to counter balance their team, and surely they can find great people from half the people out there, but the pool is definitely smaller right now (and everyone is going after it). Focus? fine. Limit? hmm.

Rather than fight over the smaller pool I get most excited about highlighting the great engineers such as Rachel as they act as role models to the entire community. Let’s put a ton of resources into growing amazing engineers from everyone on the globe and get to a point where we don’t need to put lighter fluid on the poor situation, and instead have a sustainable setup.

Until then, there may be some hardship all around. When our kids were bussed around town to integrate schools it meant a lot of time in busses. It was a pain for them and parents. As a society though all boats rose (much more rising to do).

I look forward to more posts highlighting great engineers, why they were hired, and why it is especially great that they bring diversity to the team and community. The Upworthy post does just that and I am happy that they found someone of that quality as their female engineer leader.

The right thing to do, is the right thing to do.