A short post this week to talk about something that should be obvious from a big picture point of view, and is topical because I’ve experienced it myself recently.

If you are sick, don’t come into work.

If you have been sick, but think you’re better now, still don’t come into work.

The world will continue to turn without you for a little while, and even if it doesn’t, maybe its better to find that our now, rather than later.

Patient Zero

To be clear, I am definitely not a qualified epidemiologist, but for arguments sake lets assume it is impossible to spread disease if you are not near other people.

The engineer in me knows that there are edge cases that circumvent this “rule”, for example indirect infection vectors like contaminated food and other things, but the engineer in me should learn to be quiet.

If you’re trying to maintain velocity in a development team (or throughput, choose your poison), then the spread of sickness can be one of your worst enemies. If you’re lucky everyone gets sick at once, and its all over quickly, but if you’re not its drawn out over the course of a few weeks (or months!) and is hugely disruptive to getting anything done.

As a sick person, the best thing you can do for your team is not make them sick. Sure, if you completely extract yourself from the situation then whatever it is that you are working on will suffer. That’s a fair call.

But all the other things? They will keep trucking along.

Honestly, if the thing you were working on was important enough, someone else will do it anyway, especially if its blocking their work. This is the worst case scenario though (at least as far as work-in-progress is concerned), and all it really results in is some repetition of work already done.

I’d much rather pay that price than the cascading effect that repeated waves of sickness have on development.

Centre for Disease Control

If you’re in a position of leadership, you need to make sure that your messaging is clear, and your follow up behaviour is consistent. If you’re spouting the rhetoric of “if you’re sick, stay away” but you then get annoyed when a deadline is missed or work is not progressing, you’re doing it wrong.

You need to play the long game, and trust in the fact that even though something might suffer now, you’ll be better off in the long run in terms of predictability of delivery if everyone is playing by the same rules

Organizationally, the capability to reliably and effectively work remotely is also a huge boon in this situation and can help mitigate the effect of not being co-located during the period of sickness. Don’t get me wrong, there is still a significant amount of value in reinforcing that your people should take care of themselves first, before they think about work, but the ability to work remotely allows them to ease themselves back in, even if they are not feeling 100%, and still prevents further infection.

Other things that help are:

• Small work items and low cycle time, which mostly limit the impact of a single person disappearing for a period of time
• Consistent communication, such that everyone on the team is generally aware of everything else that is going on
• Well rounded people who can do anything (even if they might be better at a small number of things), because you’re going to hurt if the only person who knows how to work on system X is quarantining themselves for a few weeks

Conclusion

In summary, if you feel sick, or if you think you might be sick at all, just stay the hell away.

When you feel better, work remotely until at least a few days have passed, just in case.

Of course, everything that I’ve written here assumes that your people use the system honestly and fairly, but really, if you find yourself in a situation where you can’t trust them in that way, then I don’t understand why they would be working with you in the first place.

To put it into context, think about how stupid the following sentence is:

“I don’t trust you to be honest that you’re sick, but I trust you to write this million dollar software critical to the existence of our business”.

You've run across a blog post that has moved!

I've got a new blog now and I'm moving over bits and pieces of content depending on my need. Also, I don't have an easy mechanism to do a permanent redirect, so I have to settle for this instead.

Click here to see the exactly same content that used to be here, except now it also has a picture.

If you fulfil some sort of team leadership role, where you maintain and possibly direct one or more teams of people to accomplish things of value to the business, then you probably have some sort of responsibility to both give (and gather) feedback to (and from) all parties involved.

Obviously, collecting, collating and sharing feedback should be something that everyone does, but if you’re in that team leadership role, then you kind of have to do it. Its your job.

For me personally, I’ve spent enough time doing it recently that I’ve managed to form some opinions about it, as is often the case when I do a thing. The natural extension of that is to share them, because honestly, what good is having an opinion if you aren’t telling everyone aaaaaallllll about it.

As a side note, I’m sure that posts with a technical slant will return as soon as I actually do something technical, but until then, enjoy my musings on the various “managementy” things that I do.

Loyalty Card

In a team leadership position, you are responsible for the well being of your colleagues and their professional development

As such, their happiness and fulfilment should be your primary concern.

Such a strategy is not necessarily mutually exclusive with the best interests of the business though, and in fact should be complementary (happy fulfilled people generally being more productive than others), but if push comes to shove, and the best interests of the business do not line up with the best interests of your people, you should stand with your people.

Moving on from that sobering point, the first step is to understand the mechanism by which you give and gather feedback. From pain points and frustrations all the way through to career and personal development opportunities and direction, you need to have an effective and consistent way to learn all about your people and to understand what they need in order to be the best they can possibly be.

Going Undercover

The most effective way to really understand the people you’re responsible for is to engage with them on a regular basis.

Not in the form of “hey, lets have a daily catchup” though, because that’s going to easily turn into a status report, and that’s not what you want. You need to share the trials and tribulations of their day to day, and not as a manager or boss, but as a colleague. I’m fairly resolutely against what I see as the traditional management approach and instead think that if you are contributing in the same way (and to the same things) that your people are, then you’re going to understand them a hell of a lot better than if you’re looking down from your ivory tower.

Realistically this means that there is probably a hard cap on the number of people that you should be responsible for.

If they are all in a single team/squad, working towards the same goal or working within a shared space, you’re probably good for ten or so. If they are split across multiple areas/goals, then you’re limit is probably less than that.

The natural extension of this is that a pure people management role feels somewhat pointless. You should deliver the same sort of things as everyone else (maybe less of them), just with additional responsibilities to the people you’re working with.

How else could you possibly understand?

Face/Off

Even if you are completely embedded within the group of people you’re responsible for, there is still value in specifically making time to talk openly and honestly with every person individually about how they are going.

To be clear, the primary focus should be on the person, how they are feeling, where they would like to go (and how you can help) and any issues or concerns they might have, with a secondary focus on how you feel about the whole situation. You want to encourage them to have enough emotional maturity to objectively evaluate themselves, and to then be able to communicate that evaluation.

If you’ve been doing your job correctly, then you shouldn’t be surprised by anything that comes out of these sessions, but they are still useful as a more focused (and private) way to discuss anything that might be relevant.

I like to keep the discussion relatively freeform, but it does help to have some talking points, like:

• Are you happy?
• Do you feel productive in your day to day?
• Do you feel like you are delivering value to the business as whole?
• How do you think we could do better as a team?
• How do you think we could do better as an organization?
• How do you think you could do better?
• Where do you want to go from here?
• Do you have any concerns or unanswered questions?
• Do you feel appropriately valued with regards to remuneration?

Don’t bombard the poor person with question after question though. Its not an interrogation.

The conversation should flow naturally with the questions above forming an underlying structure to help keep everything on track, and to provide some consistency from person to person.

That’s a Sick 360 Bro

Another mechanism is the classic “360 degree review”, where you encourage your people to send out surveys to their peers (and to complete surveys in turn) containing questions about how they are doing in various areas.

This particular mechanism has come up recently at my current workplace, so its topical for me.

I’m sure you could manage the entire process manually (paper!), but these sorts of things are typically digital (for ease of use) and are focused around getting people to anonymously comment on the people they work with in regards to the various responsibilities and expectations of the role they fill.

For example:

Bob is a Senior Software Engineer.

He is expected to:

• Solve problems, probably through software solutions (but maybe not)
• Mentor other software engineers, with a particular focus on those who are still somewhat green
• Participate in high level technical discussions

Each one of those responsibilities would have a set of questions carefully crafted and made available for Bob’s peers to fill out, usually with some sort of numerical rating. That information would then be aggregated and returned to Bob, so that he could get a sense of how he is doing.

The anonymity of this approach is easily one of its greatest strengths. Even if you’re the most friendly, least intimidating person on earth, you’re still probably going to get more honest feedback if they don’t have to look at you directly.

Even more so if you have something of a dominant personality.

Its All About The Money, Money, Money

As a final point, everything that I’ve written about in this post should be clearly separated from discussions about salary, titles and all of the accoutrements that come with them.

At best, salary is a slightly positive factor in overall happiness and fulfilment. Once a creative person is being paid enough to meet their own personal goals, more money is unlikely to make them happier.

Of course, the flip side is devastating. Not enough money or a salary that is perceived as unfair (usually when compared against others or the market average) can be a massive demotivational factor, and in the worse case, can ruin a professional relationship.

Keeping the two things separated is difficult (and honestly, a complete separation is probably impossible), but you should still aim for it all the same. The last thing you want to happen is for people to withhold information about their weaker areas (prime targets for improvement and growth) because they know that you’re going to use it against them later when you start talking about money.

Conclusion

Being even slightly responsible for the well being of another person with respect to their professional life is a big responsibility and should be treated with an immense amount of care, empathy and respect.

That is not to say that you should be soft or impotent in your approach.

You need to be strong and decisive (when necessary) and give people pokes if they need them. Be aware though, not everyone responds to the same feedback mechanisms in the same way, and you will need to be mature enough to understand that and adapt accordingly.

To end on a fairly trite note, at the very least you should aim to be the sort of person you would look towards for professional guidance.

If you’re not at least doing that, then its worth reconsidering your approach.

Where I work now, we have a position known as “Delivery Manager”. From an outside perspective, the role is a middle-management position, responsible for ensuring the smooth delivery of software to agreed upon budgets and timelines, as well as reducing the complexity and amount of information that the CTO has to deal with on a daily basis. Fairly standard stuff.

For most of my time here, I had a delivery manager. I liked him and I feel like his overall effect on the team was positive. He knew when to involve himself and when to get out of our way, though this was helped somewhat by the fact that he was located in a completely different city, so contact was sometimes sporadic, and he had to make sure that those times where we could get together were as useful as possible.

Unfortunately, a few months ago his position was made redundant for a variety of reasons, but I suspect the primary one was the location (with the organisation choosing to focus more effort in their Brisbane location).

Somewhat ironically, change is actually the only constant in life, so being able to adapt quickly is an important skill to have. If you were to choose just one thing to improve, I would recommend choosing the ability to adapt and function whatever the situation. Hone that skill to a razor edge, because it will always be applicable.

For us, the initial assumption was that we would simply get another delivery manager, except this time actually situated in the same office as us. It was getting close to the end of the year though, so we were going to have to do without for a little while, at least until the new year.

Well, its the new year now, but the question we’re all asking, is do we really need one?

The Romans Tried It

Beyond developers, there are a few other roles present in my team:

• The product owner, who is focused around what the deliver, when and how that fits in with the greater business strategy.
• The iteration manager, who is focused around the process of delivery and how to ensure that is as smooth and efficient as possible.
• The technical lead, who is focused around how to deliver and ensuring that what is delivered can be maintained and improved/extended as necessary.

It feels like between those 3 roles, a delivery manager should be redundant. Working together, this triumvirateshould be able to make decisions, provide whatever is necessary to any interested parties, and deal with the management overhead that automatically comes with people, like recruitment, evaluations, salary adjustments and so on (assuming they (as a group) are given the power to do so).

Each person in the triumvirate has their own area of speciality and should be be able to bring different things to the table when it comes to steering the team towards the best possible outcome.

Decisions made by the triumvirate would be owned by the group, not the individual. Allowing the responsibility to be shared in this way means that there are less likely to be issues resulting from a singular person trying to protect themselves and the likelihood of poor decisions is lessened by the nature of the group being able to take into account more factors than a single person.

Ego and personal ambition is reduced, because all parties should have approximately equal power, so an individual should never be able to become powerful enough to control or subsume the group as a whole.

Finally, with an odd number of people, any and all disagreements should be able to be resolved via voting, assuming no-one abstains and the options have already been reduced to 2.

It Didn’t End Well

Of course, its not all puppies and roses. All 3 participants in a triumvirate need to be mature enough to operate towards a common goal in a highly co-operative way. Like most roles in an organisation, powerful egos are detrimental to getting anything done. The upside of a triumvirate is that the impact of a powerful, out of control ego is lessened, as the other two members should be able to act and mitigate the situation.

The other downside of a triumvirate is the speed at which decisions are able to be made. A singular person in a position of power is capable of making decisions very quickly, for both good and bad. 3 people working together are unlikely to be able to decide as quickly as 1, due to a number of factors including communication overhead and differing opinions. Again this is another reason why all participants in a triumvirate must be highly mature people without ego, willing to listen to information provided and quickly construct informed opinions about a situation without colouring them with their own internal biases. A pretty tall order, if we’re being honest.

Finally, to an outside observer, having 3 people performing a single role might look inefficient, especially if they ignore that those 3 people have a wealth of responsibilities beyond acting within the triumvirate.

Google Did Much Better

A leadership structure consisting of 3 equals working together is not a new concept.

The ancient romans had at least 2 triumvirates, but to be honest, they did not end well. From the small amount of reading that I’ve done on the subject, it seems like one of the main reasons for their failure was the motivation behind their formation. In both cases, a triumvirate was established in order to avert a war due to succession disputes, so every party in the triumvirate was still acting in their own best interests rather than in the best interests of the people they should have been serving. A valuable lesson that can easily be applied with forming a triumvirate in an organisation.

A successful triumvirate can be seen in the management structure of Google back in 2010. Larry Page, Sergey Brin and Eric Schmidt worked together as a team at the very highest level of the organisation in order to help turn it into the juggernaut it is today. Each one brought different skills to the table and provided different experiences and opinions that no doubt helped them to make the best decisions that they could make. Of course, the Google triumvirate is no more as of 2011, with Larry Page stepping up to head the organisation on his own, but whatever factors went into that particular change are not easy to discern from an external viewpoint. Still, much has been written about the triumvirate structure that helped to make Google what they are today.

Conclusion

At best, all of the above is an interesting thought exercise that occurred to me as a result of my current situation. After discovering that the idea was not new, and doing a little reading, it looks like the construction of a triumvirate as a leadership structure seems to relatively uncommon. At least as far as I could see when searching on the internet. Of the examples that I did find, only 1 seemed to have an overall positive effect on parties in play (though, Roman politics is probably significantly different to organisational politics).

Being that there are a lot of people out there who have probably given this a lot more thought than I have, combined with the lack of successful case studies, I have to imagine that I have overlooked or understate some of the downsides inherent in the structure.

I imagine that its the human side of the equation that I’ve understated, which is a common mistake of mine. For all my bluster and jokes around the nature of people, I mostly assume they are good at heart, willing to subsume their own ego in favour of a better outcome for all.

The concept is also very similar to a committee, and anyone who has even interacted with a committee (especially in government) probably knows how ineffective they can be. Hopefully limiting the number of participants to 3 is enough to prevent that same level of inefficiency. The focus of any sort of structure like this needs to be around getting results in acceptable timeframes, something that I’ve never experienced from a traditional committee.

In summary, the idea seems solid on the surface, removing a layer from an organisational structure that honestly does not look like it needs to be there, but I might not be taking all the factors into account.

In contrast, writing software looks positively trivial.

I like to think that I consistently seek feedback from my colleagues, but the truth is that I’m more likely to focus on technical work. This is probably because I’m more inclined to work on solving an already acknowledged problem rather than try to find some new problems to work on, which is commonly the outcome of seeding feedback from your peers. It doesn’t help that it requires a specific mindset to really get good value from a peer review.

That’s why this time of year, when my organisation schedules its performance reviews, is good for me. Part of our review process is to gather feedback from a subset of our peers, so I get poked to do what I should be doing anyway, encouraging me to put down the tools for a little while and improve myself professionally with the help of the people around me.

When it comes to peer reviews, personally, I want brutal, unadulterated honesty. If I’ve gone out of my way to seek someone out to get a sense of how they feel about me professionally (or personally, as the two often overlap quite a lot), the last thing I want is for them to hide that because they are afraid of hurting my feelings or some similar sentiment. You really do need to have a good handle on your own emotions and ego before you embark on an a review with this in mind though.

In order to actually engage with people, you want to make sure that you’ve given them something to rally around and get the conversation started. In my case, I try to treat the peer review situation a lot like I would treat a retrospective for an agile team, with two relatively simply questions:

• What should I keep doing from your point of view?
• What should I stop doing from your point of view?

When targeted at personal and professional interactions with a colleague, these questions can lead to quite a lot of discussion and result in opportunities for improvement and growth.

Nuance

I’m a pretty blunt sort of person, as you might be able to tell from reading any of my previous posts.

For me, I want to get right at any issues that might need to be dealt with as soon as possible, taking emotion and ego out of the equation.

Not everyone is like that, and that sort of confrontational attitude can make people uncomfortable, which is the last thing you want on the table when seeking feedback. The truth of the matter is that each person is very different, and it is as much the responsibility of the person being reviewed to encourage conversation and discussion as it is the reviewer. You have to tailor your responses and comments to whoever you are interacting with, making sure not to accidentally (or on purpose) get them to close off and shut down. Nothing good will come out of that situation.

It might seem like a lot of work, when all you really want is some simple, straightforward feedback, but making sure that everyone is comfortable and open with their thoughts will get a much better result than trying to force your way through a conversation to get at the bits you deem most useful.

Hierarchy

Personally, I’m not the sort of person that puts a lot of stock in a strictly hierarchical view (organisation charts in particular bug me), mostly because I don’t like that archaic way of thinking. Bob reports to Mary reports to Jon reports to Susan just feels like a very out-dated way of thinking, where I prefer a much more collaborative approach where people rally around goals or projects rather than roles and titles. That’s not to say that you can escape from there being some people who have the responsibility (and power) to mandate a decision if the situation requires it, but this should be the exception rather than the norm.

How does this relate to peer reviews?

Well, not everyone thinks like that. Some people are quite fond of the hierarchical model for whatever reason and that can bring a whole host of issues to the process of getting honest feedback. These people are not wrong, they just have a different preference, and you need to be aware of those factors in order to ensure that you get the most out of the review process.

If someone considers themselves above you for example, you can probably count on getting somewhat honest feedback from them, because they feel like they can speak freely with no real fear of repercussion. Depending on the sort of person this can be both good and bad. If you’re really unlucky, you’ll have to engage with a psychopath who is looking to “win” the conversation and use it as some sort of powerplay. If you’re lucky, you’ll just get a good, unfiltered sense of how that person views you and your professional conduct.

The more difficult situation is when someone considers themselves to be below you, which can evoke in them a sense of fear around speaking their mind. This is a bad situation to be in, because it can be very hard to get that person to open up to you, regardless of how many times you make promises that this is a purely informal chat and that you’re interested in improving yourself, not punishing them for telling you how they feel. Again this is one of those situations where if you’ve established a positive and judgement-free relationship, you’ll probably be fine, but if the person has some deep seated issues around a hierarchical structure and your position in it, you’re going to have a bad time.

If you do identify a situation where a peer is afraid of speaking their mind due to perceived positional differences during a peer review, its probably too late. Pick someone else to get feedback from this time, and work on establishing a better relationship with that person so that you can get their feedback next time.

The Flip Side

Up to this point I’ve mostly just talked about how to get feedback from other people to improve yourself, which is only half of the story.

In order to be fair, you need to be able to be the reviewer as well, offering constructive feedback to those who request it, and, if necessary, encouraging people to seek feedback for personal growth as well. This sort of concept isn’t limited to just those in “managerial” positions either, as every team member should be working towards an environment where all members of the team are constantly looking to improve themselves via peer review.

Giving feedback requires a somewhat different set of skills to seeking it, but both have a lot of common elements (which I’ve gone through above). Really, its all about understanding the emotional and intellectual needs of the other person involved, and tailoring the communications based on that. In regards to specific feedback elements, you want to be honest, but you also want to provide a mixture of specifically addressable points alongside more general observations.

Remember, someone seeking feedback has already decided to grow as a person, so you’re just helping them zero in on the parts that are most interesting from your point of view. They are likely seeking the same thing from multiple people, so they might not even change the things you talk about, but its still a good opportunity to help them understand your point of view.

Conclusion

Seeking and giving feedback require an entirely different set of skills to solving problems with software. Both sides of the coin can very quickly end in an emotional place, even if its not intended.

From a reviewee point of view you need to be able to put ego and emotional aside and listen to what the other person has to say, while also encouraging them to say it.

From the reviewer point of view, you need to be able to speak your mind, but not alienate the person seeking feedback.

Its a delicate balancing act, but one that can generate a wealth of dividends in your professional life.

If you’re lucky, it might even make you a better person.