Contents
1.1. The Remote Paradigm Requires You to be a Better Leader1.2. Leadership Is About Creating Feelings
1.3.1. Understand What Innovation Means to Them
1.4. Embrace Your Peoples’ Individual Work-Style Preferences1.5. Support Them in Influencing Their Environment1.6. Challenge Your Engineers to Accept Responsibility
1.7.1. Manage Upward to Set Reasonable Delivery Expectations
1.8. Lead from the Front - Stay Up Late with Your Team1.9. Set Fair Responsiveness Expectations1.10. Keep Your Initiatives in Perspective with Four Pillars
1. Leadership and Leading Remotely
1.1. The Remote Paradigm Requires You
to be a Better Leader
Having taken on my first CTO position right as the COVID-19 pandemic struck, I
had no time to get to know my employees, my bosses (the co-founders), the
industry, or the product. I was no stranger to managing relationships
between onshore and offshore teams so I had that working in my favour, but
restructuring an organisation I didn’t yet know, and remotely evolving a
product and its architecture that I didn’t yet understand was going to be a
task for which I had no career precedent. I had to make up the rules for
how to run a fully remote software engineering organization on the fly.
A year and a half later, I had come to realise that the remote work paradigm
helped me create the most effective organisational strategy I have ever been a
part of. It forced myself and my team to be crisper on design,
assignment of responsibilities, crisper on guidelines in process,
architecture, and automation, and it freed me and my teams from what I saw as
the constraints, conformity, noise, and imbalance of the regular office work
environment. It also forced me also to be more thoughtful on how to
impart meaningful, effective leadership influence on people I didn’t even know
in ways I may not have thought to contemplate face to face.
1.2. Leadership Is About Creating
Feelings
I believe that fundamentally, leading remotely is only a question of how a
leader needs to modify their approach to consider all the dimensions of an
employee’s experience that they should be managing face-to-face anyway.
If as a leader you’re missing an answer for how you’d manage any of these in a
face-to-face experience, their absence in a remote role is only going to
amplify and accelerate an issue that would probably develop over time
anyway. Be it onsite onshore, remote onshore, remote offshore, employee
or contractor, it all comes down to the member feeling that the following
dimensions of their experience are being actively managed:
-
Feeling their individual intrinsic motivations are understood and that
this understanding modulates the behavioural expectations, and the
expectations and empowerments commensurate with their role
- Feeling they are a part of something meaningful
- Feeling respected and recognised
-
Feeling they can trust their leadership (to be sensible, consistent,
observant, and fair)
- Feeling work-life balance is something they’ve no need to argue for
- Feeling like they can influence their environment
- Feeling growth opportunities exist
-
Feeling fairly compensated (more on this as it relates to offshore and
contract staff later)
-
Feeling safe to raise issues and suggestions to receptive supervisors
Together, to the extent that you manage them, these dimensions represent your
culture. I’ll restate that these dimensions need to be actively
managed. If these aren’t conversations you’re having from time to time
on an individual basis now, or if you don’t contemplate if or how these live
in your department, you should start. Done from a genuine place, the
active engagement with your staff will create meaningful connections, and if
you follow through with what these items require of you, you’ll generate for
them a sense of place, and in them a sense of loyalty. If you’re only
managing your staff’s task list, you’re missing out on leading the person,
instead only managing a resource. In later sections of this series I’ll
spend time describing ways to develop these.
1.3. Understand Your Team Members’
Motivations
It’s obvious to state that not everyone is moved by the same things, yet it’s
astonishing how often I’ve seen this do nothing to meaningfully modulate
managers’ styles and decision making on a person-by-person basis. If you
were to consider this from the perspective of assessing an employee’s risk of
leaving, the tangible ones are generally:
- Compensation
- Job stability
- Promotion in title (especially for up-and-comers)
-
Greater technical skill in their stack of interest, or practices in
general
- More (or less) management responsibility
- Interest in the industry/business area
- Contribution to social causes
If you don’t know where your engineers sit in respect to each of these facets,
you may get a surprise when one day they walk out the door because some of
their main goals weren’t being met. When new people join your team, and
somewhat regularly thereafter (I’ve found quarterly is a good guideline),
these are questions you need to ask them and doing so will further contribute
to their sense that you value them.
Often, the correct remedy for mismatches in many of these is realignment
within the organization to balance career growth, skills, and output, but
actively managed with the staff member instead of surprising them with it
every time you release a new org chart.
I’ll spend a moment now outlining just a few areas in which I’ve commonly seen
misalignment leading to attrition, suboptimal outcomes, and missed
opportunities.
1.3.1. Understand What Innovation Means
to Them
Innovation often means a different thing to engineers versus product and
business people, and you have to manage expectations. Highly competitive
engineers generally like to innovate for technology’s sake – to try something
new by experimenting with emerging technologies. Business leaders like
to innovate because they have a problem to solve. Yet another class of
engineers are not so innovation-driven necessarily, prefer a more status-quo
kind of environment, and just want to get the job done well. There can
be a place for all of these kinds of engineers, depending on your goals, and
you need to know in which camp they sit.
From the standpoint of an engineer, the curb appeal often lies in their
gaining a competitive advantage in the marketplace by being associated with
development or use of emerging technologies, as mentioned above. There
is an excitement for them that comes with not working on the “same old stack”,
or for that matter being involved in an experimental R&D program to
conceive their own new stack components because they believe existing ones do
not solve their problem well (for example, React was created by Facebook for
just such a reason). Naturally, not every organization has the luxury or
purpose for creating such a function.
From your perspective as a technology executive, unless there is truly a real
question of value proposition (competitive advantage, efficiencies) for the
development or utilization of a bleeding-edge stack or technology, there are
risks and pitfalls to consider in not using something tried, true, and
current. More mature stacks are better tested, more functionally
comprehensive, performant, secure, and have large communities contributing to
an expansive knowledge base. This is all pretty self-evident and I’m not
making this point for its own sake. However, depending on your scenario
not all team members’ goals will align with your own risk appetite or
technology goals, and this is something you must come to know of your team
members on an individual basis. You need to understand if your own
technology plan excites them – or is at least match-fit.
Simply put, make sure your engineer is happy to be at their assigned place on
the innovation spectrum. If they’re not there now, and if there aren’t
expected to be any roadmap developments where they could slot in in the
reasonable future, it’s just a matter of time before that misalignment creates
issues. Either have this conversation actively and plan accordingly, or
they’ll make the decision for you and leave you down a set of hands.
1.3.2. Don’t Give Technicians
Managerial Responsibility They Don’t Want
Some engineers want to climb the management ladder, some want to climb the
technical one, and some are happy where they at their stage of career
progression. Understanding which seat they’re in is important because
absent any other consideration, the job descriptions of team leads, scrum
masters, and straight-up engineers are different; misalignment here can
quickly lower individual or team performance and unity.
I’ve often seen Scrum teams with one of their developers assigned as the Scrum
Master. Unless you have a management-track engineer who wants to excel
here and is proven to be truly impartial in the two roles, this can be a
problematic union. Lack of impartiality creates a conflict of interests
and is accompanied with:
-
Disgruntlement with the expectations of the dual role (possibly not even
really wanting to wear both hats)
-
Poorly specified stories or tasks that aren’t adequate for the purposes of
test case specification, leading to quality issues
-
Built-in, undocumented assumptions in technically written work items
- Lack of transparency in team progress (deliberately or ineptly)
-
Poor time management of the SM themselves and of team members (it’s not
their forte)
-
Tendency to not advocate enough for the true business need (they don’t
tend to think in terms of the five-whys)
- Outright lack of people management skill
Ultimately, it can cause quality issues, not getting what you want, and cost
and time overruns because the team isn’t getting the qualified leadership and
advocacy it needs.
1.4. Embrace Your Peoples’ Individual
Work-Style Preferences
I’m distinctly unconventional in my preferences for my ideal physical working
environment. As a place for deliberate purposeful collaboration the
traditional office environment has always been fine and enjoyable for me – in
collaboration sessions I get a buzz from the energy of the room.
However, I’ve always found it completely suboptimal as an environment in which
to get myself into the kind of creative head space I need to solve large-scale
problems. As an engineer, architect, or manager this is a big problem
for me as these are all highly creative, analytical roles. So much so,
in fact, that the bulk of my truly deep thinking needed to be done at home,
after hours, where I could control my environment. A lot of people use
their after-hours to catch up on emails or writing policy documents for
example, but for me that was often being done during the day. I did not
produce my best work in a bright, busy room with people constantly walking by
and stopping to ask questions. I know I’m not alone.
The remote work paradigm opens up the opportunity to let team members be their
own person. Save the requirement to be available for stand-ups, general
meetings, or collaboration sessions, let your team members run their own
routine. I’m one to shut my eyes, put my hands behind my head, and put
my feet up on the desk in a fully darkened room with headphones on. Try
getting away with that in a standard office environment. If you’ve got a
night owl, don’t expect them to be contactable outside of agreed hours except
in planned or exceptional circumstances. If they want to start work
early so they can take off at 2pm for family activities, let them.
Manage expectations and around availability and accountability for work
product and you have the framework to allow them to create their own optimal
environment. These are things you need anyway, and besides, looking over
their shoulders between 8 and 5 doesn’t get you very much. It’s
tantamount to an implicit assumption that it’s ok to bother them between those
hours. I’ll continue the theme on accountability in a later section,
“Remote Software Engineering Challenges”.
1.5. Support Them in Influencing Their
Environment
Creating a structure where your staff can influence their environment is
critical to an engaged team culture. This is something you want as an
executive – it quickly becomes tiring to attempt to anticipate and implement
every initiative you think the team needs in an attempt to influence it for
them, and they may not necessarily follow you if they feel you’ve missed the
mark. Sure, from time to time some teams genuinely don’t have the ideas
to improve their work environment (there can be a few reasons for this,
especially in a transformation project), but generally, most teams know where
they need support to improve the quality of their work experience. All
they need is your backing to make it so, as long as it makes sense. If
it doesn’t make sense, you still need to think about the outcome they were
going for when you suggest an alternative.
Each team member will live with stresses, frictions, and inefficiencies that
make that daily or even hourly experiences problematic. Anything with
the way teams coordinate their efforts in related areas of source code, to the
process of reverse merging a team’s code across a shared code base, to the
release process, to issues in Scrum management can cause problems that detract
from available time and their general enjoyment at work. You’ll be in a
bad spot if you don’t listen to and support their suggestions – with some
common sense and experience applied of course – because you need your people
to want to make a difference, and for this they need to feel heard.
Ironically, the place where I’ve seen frequent failures is in the part of the
Scrum process whose explicit purpose is to create a continual improvement
culture – the Retrospective ceremony. I’ve witnessed time and again
organisations whose teams attend the ceremony, do their keep/stop/start
exercise, only to find a few sprints down the road that few things have
changed in a meaningful way. The teams disengage and eventually, under
the delivery pressures of a system and process that isn’t improving, adopt the
mentality that nothing will ever change.
This phenomenon is cancer to a department. Ensuring continual
improvement is a core responsibility as an executive and if this phenomenon is
happening, you need to find out why. The obstacles need to be identified
and overcome. Is it Scrum Masters or managers who are not taking their
suggestions seriously? Are they unable to articulate them? Are
they unable to see the whole picture, think creatively, and create a workable
incremental suggestion that can see progress in the right direction? Are
you yourself supporting your managers adequately? The answer to this
problem may ultimately come down to something you yourself need to improve
on. Their suggestions need to be implemented.
1.6. Challenge Your Engineers to Accept
Responsibility
When solutioning, make your architect encourage your engineers to give their
own design thoughts before pushing a design down to them. They’ll learn
more if they challenge their own thinking and it will develop a sense of
ownership, and of themselves becoming part of the platform. Nothing is
worse for a budding engineer than having a design pushed down with little
opportunity to provide input and to code it like an automaton. That is
not leadership – it is just poor management. Also, as far as remote task
management and accountability is concerned, your team is a lot more likely to
do the work and not slack off if they’re the ones that lay out how they want
to approach a problem.
1.7. Insist on Work-Life Balance
It goes without saying that we want our staff to have an equitable work life
balance in which they feel they have quality of work life and quality of
personal life, but we all know in the modern workplace this can be a hard goal
to realize. Especially in the start-up space, operational tempo and
commitments can be high, timelines can be short, and resourcing levels may not
be adequate to wholly meet all needs. Executives, managers and
lower-level employees alike get stressed to unhealthy levels. They come
to resent this situation and ultimately move on in search of greener, calmer
pastures. You’ve lost talent, and you’ve lost knowledge.
There are two main ways to help ensure this is not the experience your staff
will have. As I’ll discuss in the following sections, manage reasonable
delivery expectations and risks with senior leadership, identify and manage
inefficiencies (broadly speaking) in your staff’s work habits and processes
that increase workload, reinforce that you expect them to work reasonable
hours, and if it comes down to it, recognize and stave-off fatigue.
1.7.1. Manage Upward to Set Reasonable
Delivery Expectations
A company with an aggressive growth strategy is going to continue to push all
the time; senior leadership knows they’re asking a lot, and they’re going to
ask you to balance it. You cannot often outright say no to the business
when asked to work on new initiatives, and you also cannot just promise
everything and push the work down to the staff without controls, either.
You must work out what you have to reason with, and what price leadership is
prepared to pay for accepting new work. Give them options, be it a
request for more resources, reduction in scope in some places, bumping some
items further down roadmap, accumulating some technical debt, or sacrificing
some of the “ilities” for a spell.
Any reasonable business leader is going to appreciate the options you give
them as it is responsible of you to do so; you’re illuminating the risks that
are created that they want and need to understand. If they don’t like
the price or the risks, they have the option to decide to defer this or
another initiative. You haven’t said no, and you’ve empowered them with
the information needed to make the choice themselves.
1.7.2. Recognise and Eliminate
Engineering Inefficiencies
This subsection is going to be so short as to appear to whitewash some very
complex topics – some of which I discuss in some detail in other parts of this
retrospective series – but I point them out in this context because I want to
highlight their abilities to influence how much time your staff can spend
doing things inefficiently, and therefore their direct impact on work-life
balance and overall job satisfaction.
It can be hard to influence all the extra-departmental factors that contribute
to long work hours, yet make no mistake, a great many of the conditions that
can cause long work hours are purely intra-departmental, can very much be
influenced, and if addressed can entirely be expected to cause work effort to
trend downward:
-
Provision of incomplete or aggressive delivery estimates to management,
perhaps due to inadequate architectural oversight, not considering
non-coding activities in the estimate (meetings), or just plain lack of
experience and understanding of the realities of the task
-
Not saying no when they think something is not realistically achievable
and trying anyway
-
No attention to code quality, thus driving up development and knowledge
management cost, and the chance of bugs along with it
-
Poorly written user stories or task descriptions that create confusion,
require additional consultation to understand, and that potentially blow
out estimates
-
Poor quality assurance, causing issues to be detected too late in the
release cycle, resulting in the inefficiencies of context switching
between bugs and planned work
-
Bad or missing continuous integration/continuous delivery mechanism,
causing manual work
-
Of course, this is all easier said than done, but this is your work.
All else being equal, engineers won’t have a quality life if these go
unmanaged.
The need for a sense of self-determination for staff is critical here (I go
into this more in the section “Lessons in Scrum”). Most people will work
in suboptimal conditions for a time, but if their feedback on ways to create
efficiencies is not openly received and supported, they will turn off very
quickly. No one wants to work when they don’t believe anything they do
can will make a difference to uncomfortable working conditions that require
too much of them out of hours.
1.7.3. Recognise and Mitigate Fatigue -
Don’t Be Stingy with Your Time
To me, the prevalence of stringent, inflexible 2-week vacation and floating
holiday policies is a sign of lack of understanding of the way people want to
function. I go against the standard corporate grain in that I think it’s
a failing model. It certainly never worked for me, anyway. Any
time I’ve gone into my single 2 week per year vacation I have done so
frazzled, worn out, and worrying about what will await me upon my
return. I’d dread my return to work on a daily basis, having barely been
mentally ready to return, and in fact would go so far as to say I often
resented my return. The final insult is the year long wait you must
endure before getting a reasonable break again. Almost everyone has this
experience and yet in the interests of ease of management and equality for
all, these policies stick around. My employers’ HR strategies didn’t
include creative ways to use time off as a way to keep me rested, engaged, and
productive.
Moreover, budget for financial incentives is typically limited and may not be
sufficient to recognize the hard work of all of your staff in a meaningful
way. If you only have a 30k bonus budget across a 50 person team,
someone is missing out, even if they made a major contribution and burned
midnight oil for you. Even a thousand dollars once a year isn’t
particularly meaningful, and done once a year is certainly not a way to
incentivize an employee to keep up the good work. Moreover, giving
employees money does absolutely nothing to manage fatigue. Sure, on the
face of it, it shows they’re appreciated, but think about the unspoken
undertone of this reward: “please don’t leave, and by the way another such
reward is contingent on keeping up that pace of delivery”. This is
awful.
To be clear, I’m not arguing against working harder when required. Yes,
sometimes people need to work longer hours to get beyond a milestone when a
delivery date is approaching, or when an issue has been discovered that
changes the assumptions under which a design was made and thus a change to the
estimate, and everyone understands that. However, it doesn’t mean it is
desirable or sustainable, and it cannot be the status quo. People need
time off in the middle of difficult periods, and they should not have to dig
into their PTO or sick days to get it. Leave their PTO to take vacation
and enjoy their families.
The answer – simply giving an unaccountable day off in the middle of a tough
run is an easy and cost-effective way to manage your peoples’ fatigue.
It actually gives them time off to relax their minds. It recognizes that
mental burnout is real and cannot be ignored. It shows you care and want
them to have balance in their work life. Don’t wait for them to ask for
it – be observant, watch for the early signs of onset of fatigue, and give it
to them before they become fatigued. It’s a lot cheaper than replacing
your people once they get burned out. As a technology executive, you
should insist on having the discretionary flexibility to execute this for
every employee. Naturally, be level in your application of this so that
you’re mindful of the possibility of inequity.
For me this has proven to be a valuable tool, even for offshore
resources. The fact that they’re contractors doesn’t mean they are any
less important as contributors, and their fatigue needs managing too.
This kind of time off needs to be reported to the vendor, but it should be
made very clear to them that the vendor must still pay the contractor’s
compensation for the day off, and as a customer, you will ensure that the
vendor is paid for that time; you’ve got that hourly budgeted anyway. I
discuss this more in the section “Managing Offshore Vendor Staff”.
1.8. Lead from the Front - Stay Up Late
with Your Team
The remote work paradigm provides some serious opportunities when it comes to
having to battle through some issues with your team.
No one respects an armchair general. If your teams’ activities see them
working harder than normal and late into the night, you’d better be in amongst
it doing whatever you can to make them know their extra efforts are
appreciated, to unblock them when needed, and to provide general comic
relief. Leading from the front means being amongst your team when things
are tough. Now – this does not mean micromanaging the effort. If
they are working late and need questions answered, be instantly available on
your communication tools.
I’ve “presided” over many a late-night effort due to anything from production
issues, releases gone wrong, analysis of problems to work out a plan of
action, and more. If I’ve asked the team to continue to work past the
normal end of the day into the evening or even into the weekend, I’ve set up a
long-running video conference bridge, left video off while no one is
discussing actively, but when there is discussion, I’d turn my video and
microphone on. They could see me, they knew I was listening to their
thinking and mostly staying out of the way unless they needed me. From
time to time I’d suggest we take 15 mins for a coffee break, which made it
feel like we were taking a break together. Naturally they knew I was
using the late night opportunity to do my own work too, but the most important
thing they knew was that I was not out living the good life while they were
working late. I was there to be on video the instant one of them
messaged me. The team loved it, and moreover, it truly felt like a
bonding experience. This is such a simple thing to do, and I cannot
overstate how impactful it is. If you’re there for them, they’ll be
there for you. I’ve experienced this outcome time and again.
Importantly, know when to call it a night. When working late the team is
going to be nervous about calling it a night because they aren’t always clear
exactly when it’s ok to down tools. Take this concern away from
them. Not many good decisions get made late at night anyway, and if it
is clear the work effort required to fix an issue is going to last into the
next day, give them a break, let them rest up, and reconvene in the morning
(assuming operationally you can, of course). They’ll appreciate that
you’re supporting a positive state of mind.
Lastly – especially if they’ve a family – let them take a break after work,
have dinner, put their kids to bed, and then resume together at a set time.
1.9. Set Fair Responsiveness
Expectations
In the days of 100% in-office work, as an architect or executive I always
wrestled with the concept of the open-door policy. It encourages
undisciplined use of time in a manner insensitive to an issue’s true
priority. Your time as an executive is important and you need focus
also. Of course, in the remote paradigm messaging platforms make
disruption even easier and it’s reasonable to set expectations around when
people can contact you and how quickly you’ll get back to them.
In your instant messaging tool of choice, establish high priority channels to
which people can reach out for urgent needs, and otherwise mute your
notifications. For example, set up “CTO Immediate, CTO 2 Hour, CTO 4
Hour” and honour those windows, and in any other channel get back to them as
soon as it is convenient, even if it is end of day.
Similarly, don’t expect your team members to reply immediately to you,
either. If something needs urgent discussion, post a message to a public
high priority channel requesting a specific person or team so that they can
better manage notifications on their private and team channels.
Otherwise, set expectations that they’ll get back to you at their next
convenience, and in any event not later than end of day.
Lastly, make it clear to your team that if you’re sending emails at night
because it’s the only time you can get to them, there should be no expectation
of a reply before work starts the next day. They should not need to be
monitoring or responding to any work communication channel after hours unless
by prior arrangement.
1.10. Keep Your Initiatives in
Perspective With Four Pillars
We all know the myriad challenges that come with remote work and I’ve no
reason to belabour those. I do have my own take on some specific
software engineering management challenges, however, so I will spend a little
time on this topic momentarily. As this essay series goes on to
describe, there are many interdependent disciplines and considerations
involved in managing the more nuanced side of a software engineering
organisation. With so many of them in play it can be easy to lose the
forest through the trees; you can lose sight of the ones most important for
your organisation’s current evolutionary stage.
I believe these disciplines and considerations can be seen as the
underpinnings of a small number of fundamental thoughts that relate them all
to each other; in the absence of a construct, they just seem like items on a
very long to-do list. I’m going to describe these thoughts as
“pillars”. A disclaimer: there are several different “four pillar”
constructs out there that touch on various aspects of leadership, management,
software engineering practice, and more. I’m going to introduce mine as
“The Four Pillars of Software Engineering Leadership”: 1
- Make your people want to stay engaged
- Define very clear and demonstrable outputs
- Create focus and try not to achieve too much at once
- Continually improve
Stated individually these seem obvious and without much value but have a think
it by way of some examples. If you’re struggling with cultural issues
for any of a multitude of reasons, you’re almost certainly going to have an
issue supporting the first pillar. If input from sprint retrospectives
isn’t implemented, you’ll impact the first and fourth pillars. If you
have your teams spread too thinly across too many initiatives you lose
traceability and focus and you affect both the second and third pillars,
arguably with follow-on effects to the first pillar too. If you have
many continual improvement initiatives – which on the face of it sounds great
– you’ll undermine the third pillar. If you take it that all four
pillars must stand for your department to be healthy, accept that dysfunction
in one will reverberate across the others.
If you think in terms of the pillars it can help put your in-flight activities
and initiatives into perspective, driving focus toward the ones that will most
directly support the success of your engineering efforts. They help you
visualise your problems from the top down – your main imperatives – and then
drill down to where the work is. Anything else you have going on that
doesn’t meaningfully support these might just be noise.
All told and simply put, you need to be able to attest: “as a leader I know my
people want to be here, they know exactly that they’re to do, we’re achieving
the right amount of demonstrable work, and we’re getting better all the time”.
1.11. Understand Remote Engineering’s
Destabilising Forces
Naturally you can apply the four pillars concept to any engineering
organisation, and as broad as all the contributing disciplines and
considerations are (again, that we cover throughout the remainder of this
series), it’s worth introducing those in this section because in a remote
world there are more forces negatively influencing your ability to keep those
pillars standing:
- People feeling disengaged from the mission
- People feeling isolated from other team members
-
Lack of access to the engineering coaching they need that would be easily
obtained in person
- Difficulty in brainstorming, ideation, and design
-
For yourself and your managers, the following challenges also present:
-
Difficulty ensuring people are staying focused on their work, working
honest hours, and staying accountable
-
Difficulty ensuring out-of-band continual improvement initiatives are
implemented
- Difficulty getting people to speak up during meetings
-
All of these challenges can slow a department down considerably and dent
your culture. Some examples of ways in which you can combat these
for your engineers follow:
-
Keep your people engaged by sharing case studies and success stories, keep
them abreast of product roadmap, and encourage them to present their ideas
if they see opportunities that the business may not see, and do regular
highlights of great work.
-
If possible, reduce feelings of isolation by getting your team together in
person “somewhat” regularly, but seriously reduce work expectations when
you do. Do something people-centric and not in the office.
Avoid them checking emails between activities. If your team is very
distributed, conduct conference call “happy hours” well before the end of
the workday so it doesn’t come out of their family time, and then give
them the rest of the day off.
-
Keep developer coaching going with regular team sessions given by your
Architect or senior engineers. Point out undesirable coding patterns
and how to migrate them to a desirable state. Make sure this time is
budgeted in their scrum commitments for all involved. Don’t make
them pay the price of losing their lunch hour for “brownbag” coaching
sessions.
-
Enhance design and ideation sessions by providing your team with good
pen-based tablets and use a whiteboard collaboration tool so they can mark
up each others’ diagrams. Before turning a session into a
free-for-all, establish the problem statement well ahead of time to give
them time to create their own diagrams, and set an agenda so they can
present them.
-
Ensure developer accountability by having them showcase their work to
their team lead daily – not just functional end of sprint style demos but
their individual input needs to be on display. They cannot be
allowed to go several days in a sprint saying they’re working on stuff
when they really aren’t. When they’re asked to make an excursion
from process it can make it hard to demonstrate accountability, so limit
those as much as possible and document when it was required.
-
Ensure you’re getting motion on continual improvement initiatives by
managing a register, and budget sprint time for your engineers for it;
continual improvement has a cost and they may not always be managed as
sprint deliverables as much as side projects, but this should not be
expected to be net plus over their regular work product.
-
Encourage more active participation in meetings by asking random people
what their perspective is on a particular topic of conversation. It
will keep them on their toes and disincentivise them from doing something
else off camera. If something they are working on is that important
that they feel the need to multitask during a meeting, it is better to
have that conversation openly and excuse people if required.
Next Up
The leadership thinking in this post has been mostly general, but naturally employees and contractors at different levels in your organisation need to be managed with more techniques specific to their level. In the next few posts I'm going to address those areas, starting with managers.
You can view my next post titled "Managing Managers" here.
1. I’ll also note that there are some other ideas that might fairly make cameos as pillars here too, such as “focus on value”. Although naturally focus on value is important for the organisation holistically, for the sake of this series my platform is more about making a healthy engineering department, and less about the business decisions that drive the right features into the product. You could argue that “automation” is a pillar too (in fact ITIL® 4 does, as a “principle” in their parlance), but I count automation as a way to achieve continual improvement.