What to consider when growing your team


 

In the course of our working lives, we have to make a whole lot of decisions. In this entry, I would like to take the time to reflect on what I think are the most important decisions you have to make, hiring, firing, and promoting.

As the leader of your team, it is your responsibility to nurture it to maturity. This means you can not abdicate hiring decisions to HR, staffing firm or even hiring system.

Obviously most of us don’t really originate the teams we lead, we inherit them, still your most important work remains this team, when you took on the job, you became accountable for its performance.

With that said, let me delve right into what it takes to make great staffing decisions for your team.

What does each role do?

A characteristic of the modern economy is specialization. Within our teams, this manifests as highly specialized roles.

For example in a tech team you may have:

  • Backend developer
  • Front developer
  • Designer
  • UXer

Depending on your business even more nuanced roles may come up.

Looking at this composition, the most obvious take away is none of the team members are any good by themselves. What good does a Designer do if no one translates her designs to a working system?

As I stress in other posts, tech is an organ of the business, it gets its raison d’être from the business of which it is a part.

Thus your duty as the leader of the team is to carefully consider (best done with the team) what value the team offers to the business. Once this is done, consider how each role contributes to the generation of this value.

The exercise will help you more clearly see the roles, who would fit in them, missing roles and even redundant roles.

Remember, the character of the roles changes with the rhythms of the business. An example would be the perfect backend engineer role when the business serviced 20 customers may fit the bill for an SRE engineer now that the business serves 100 customers.

What strengths are needed for each position?

I used to believe all humans are equal in ability and temperament, all that matters is the effort put into the work. I have come to learn from experience this is not true.

Each person comes equipped with a natural set of strengths and weaknesses.

There is no point in trying to mold a naturally creative but otherwise disorganized person as your coordinator. Likewise, it would be foolish to strap your “by the rules kind of gal” into a position requiring constant adaptation.

Now, this is not to say weaknesses can’t be overcome, of course, they can, the challenge is even if they are, what you end up with is at best an average performer.

The point here is not to eliminate glaring weaknesses, even the most charming salesperson is to be relieved of his role if he repeatedly shows up to important meetings inebriated.

What are behaviors to look out for?

In time, I have come to realize people judge themselves by their intentions and not by their actions. This would be ok if intentions and actions match, but you must have come across individuals who consistently act against their self-interest in ways which dumbfound even themselves.

What is the implication of this odd fact as you make hiring decisions?

You must focus on behaviors and not on statements of intent. You must teach yourself to drill into the details. If an interviewee says I taught myself python, ask what projects they have actually done in this project, then ask to see the codebase. If you have the time, see the commit history!

When defining the role, think deeply about what behaviors they will need to exhibit in order to be successful in this role. This can help you and other hiring managers ask the right questions.

For example, I hold people who have self-taught in high regard. There is something special about someone who after all the stress of their day jobs still manages to get home and finish a course not directly related to their current job. This is a behavior, not an intent.

Now that they have joined, what next?

I am not one easily accused of micromanagement. I believe each team member should be able to set their own working style and priorities as long as they align with the business goals.

The problem is if a new hire or recently promoted staffer has no idea what the role involves. In this case, some guidance is needed.

This is because a person’s performance depends on both their ability and experience on the job. So a person who has great ability but no idea what the job is all about will likely fail. A person with low ability should likely not be in your team at all.

Personally, I use OKRs (Objectives and Key results). Together, we brainstorm on 5-10 objectives for the next quarter, I give them a week to think about it, we then whittle down the list to the top 3 and attach some measurable results to tell us if they met the objectives.

How do you make staffing decisions? Talk to me in the comment section below, my Linked in chenchajacob  or my twitter @jchex

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Objectives of a Software Project Manager

In the friendly banter after a routine management meeting, a colleague asked me.

If I was to become a software project manager, what advice would you give me?

For context, the lady leads her own team successfully and has the requisite project management educational background. So obviously she did not care for a run through on the latest PMP manual.

I thought a while about this and distilled what I think are the most important objectives for a SPM.

  1. Get it done faster
  2. Make commitments you can keep
  3. Make progress visible

Get it done faster

I am a otarian, in one of our Saturday fellowships, the speaker made a comment which has stuck with me for 3 years now.

I am a slave of time

After the session, I tracked him down to understand what he meant by this cryptic statement. He mentioned to me, of everything else in our physical universe, time is the only thing we have absolutely no leverage on. Given enough resources almost anything else can be changed, but time waits for no man.

In the world of software, this is especially true. Engineers are usually one of the highest paid resources in a business. If you happen to be accountable for their time, you must take this responsibility seriously.

Even more importantly, the features being released to the business are time sensitive.

Bill Gross, in one of the most popular ted talks in the business category makes the case, timing is the most important factor in the success of a startup

For a business which is going concern, you can be sure what you are building is relevant only now, take too long and whatever you deliver may just as well be garbage.

Figure out what too long means for your business.

Make commitments you can keep

Why is Uber so successful?

Some may argue its the comfort, the quality of the cars, or even a great rating system. I posit its because they are reliable.

When you call for an Uber, you never have to worry wether one will be available, or that it will be where you are within 15 minutes (upper limit) or that you will get home safely. Yes, you may at times pay more but your ride will be there.

If you may even allow me the audacity to claim, reliability is the most important factor for career success.

There is a characteristic of a good number of people I find very annoying. You have a discussion which yields some action points, perhaps you note yours down. Looking into their eyes, you can see a lazy glaze, you feel a premonition, in time an excuse is coming. Will it be they forgot the task? Maybe they were too busy? Who knows.

Don’t let fancy degrees fool you. Business is not a high iq sport, the ability to deliver consistently is more valuable than brilliant but sporadic outputs.

As a SPM, you are now in charge of more than just your own output, you are now going to be held accountable for commitments made by the entire team.

Be reliable.

Make progress visible

The most important objective of any manager is to illicit top performance for the team they serve.

This is doubly true for development where the work output quality is not self evident.

To understand why its so important to show progress, let’s take a moment to think about what motivates your team. Before they were the rockstar engineers you now know and love. Your team mates were struggling noobies. Now learning programming is a painful experience. For most part nothing makes sense, the errors are cryptic and the machine does what it darn well pleases. Wins are few and far spread, before it all clicks.

Yet this feeling of progress, the joy of competence is worth it.

In the work environment suddenly everything is tipped around, the work is rarely technically challenging, most apps are glorified database abstraction layers after all. Business requirements are however ambiguous and constantly changing, the hierarchy passes on dictates without pause to explain why it matters. This is a different kind of jungle, how is one to know they are getting better?

This is where the SPM comes in, build your team a racetrack. Absorb all the uncertainty and spit out a challenge, one the engineers will know for sure when it’s accomplished, be able to access their current position relative to it and understand how well they actually did.

From your fellow business managers, expect some skepticism, after all, the head of commerce brought in 10% more sales this quarter, what did you bring?

Good progress indicators help you demonstrate what you are doing and why it’s essential.

Make progress measurable.

In your opinion, what are the three most important objectives of a Software Project Manager? Talk to me in the comment section below, my Linked in chenchajacob  or my twitter @jchex

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Why have a deployment pipeline

 

When I was starting out on my software development path, I landed on a handy little trick.

On the root of the project, I would put in a new file deployment.md.

On this file, I would write out all the steps I took to deploy the code. This includes even code to ssh

ssh app@172.65.45.32

Use password: secret

This system worked quite well. After all, I was a lone wolf and everything I deployed needed to work on only one server.

Of course, nowadays the systems we write are not as trivial:

  • They require coordination across teams
  • Security is a key concern
  • Downtime is unacceptable
  • Different services run on different servers

With this new conditions, I have learnt to embrace a new concept, automated deployment pipelines.

In this entry, we shall be looking at the benefits to be experienced in deploying the new system.

Feedback to all teams involved

In deployment just as in development, you will come across errors, bugs as it were. You may think this is a problem, I don’t think it is, such is the nature of the world. The problem would be not knowing what is going wrong.

Automation helps in the sense the bug happens every single time, not just when the sloppy developer is pushing their code. This makes it far easier to diagnose and thus permanently fix the issue.

Furthermore, each team formally or otherwise has the DevOps expert. But what happens if the person gets sick and the system goes down?

A proper pipeline is a crystallization of this professionals knowhow, it can be used even in their absence. Even better, other devs can explore what he did to add to their own knowledge.

Less documentation

Documentation is a whole lot of fun, isn’t it?

Without a deployment pipeline, there must be documentation guiding the rest of the team on:

  • The steps to deploy
  • How they will know they have been successful
  • The various error states and how to recover

Even if you are able to successfully do this, the work quickly decays and there is no obvious way of seeing this happen.

A CD pipeline is in tune with your code. The moment it breaks, the code can’t go into production. This means:

  • The deployment pipeline will always be up to date
  • The steps are self-documenting

Basically unit tests on steroids.

Free up time

To carry out a successful deployment. The developer needs to have a working knowledge of :

  • Unix commands
  • Servers
  • Proxies and load balancing
  • Networking
  • Etc

Beyond trivial websites, the work is not child’s play.

Yet after the first time, it is very repetitive. Which creates the dilemma for you, hiring expensive staff to work on rote stuff and bad for the professional who gets to basically bang their head on the keyboard every day.

A deployment pipeline frees up the devs to work on high value creative work. You will notice this in the form of higher engagement from them.

Easy to verify

Suppose the work was outsourced, the consultants then give you a working system together with the source code.

What happens if for some reason it went down and you need to restart it?

Sure, you can always call them back in and trust somehow the developer who worked on it is still employed with them and has retained a working knowledge of your system.

Quite the gamble my friend.

Alternatively, they could show you during the demo which button to push to bring the whole system right back up!

In conclusion, automated deployment will make your life much easier. With the rising popularity of containerization and development of great orchestration tools like Kubernetes, you really have no excuse to still be doing manual deployments.

How do you deploy software in your own organization? Talk to me in the comment section below, my Linked in chenchajacob  or my twitter @jchexFacebooktwittergoogle_plusredditpinterestlinkedinmail