1.2. Leadership Is About Creating Feelings
1.3.1. Understand What Innovation Means to Them
1.4. Embrace Your Peoples’ Individual Work-Style Preferences
1.5. Support Them in Influencing Their Environment
1.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 Team
1.9. Set Fair Responsiveness Expectations
1.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.
No comments:
Post a Comment