Development team management involves a combination of technical leadership, project management, and the ability to grow and nurture a team. These skills have never been more important, especially with the rise of remote work both across industries and around the world. The ability to delegate decision-making is key to team engagement. Review our inventory of tutorials, interviews, and first-hand accounts of improving the team dynamic.
Motivated by some recent M&A news and general productivity pressures in time of tight budgets, we present some anti-patterns to the use of engineering metrics and give an overview of how to use metrics for productivity insights instead. First, let us first start with what to avoid: Anti-Pattern to Engineering Metrics Lines of code written: While lines of code can be a proxy metric for how much code you have to maintain (and therefore costs to incur), it has been proven to be a terrible metric for productivity. This shouldn’t need much explanation, but: Output does not necessarily equate to the outcome. Different programming languages have different verbosity, and e.g., just including some open-source packages or pasting in some code from Stack Overflow does not make you more productive. And, of course, solving hard problems often does not require a lot of code but a lot of thinking, exploration, and collaboration. Complexity or salience of code: Complex code is not good code. Someone else has to read, understand, and maintain it. Salient code (let’s interpret this as “most notable”) can be worth noting, but that does not make you a good team player or show any consistency. One key point here: Software development is a team sport. However, every company has some rock stars who are able to do things that others cannot, but that does not mean you only want rock stars who cannot work with others. This is especially true if you have more than on star with similar traits. Number of PRs/Reviews: Now, this is a bit more on the grey side. Of course, if you can churn out a lot of pull requests (PRs), this typically means it is work associated with some feature spec (at least one would hope so). This means it is at least going in the direction that is perceived as customer value. But on their own, PRs are again a proxy of the amount of work that requires maintenance and a metric that is prone to gaming. Sure, you can do a lot of small PRs and “clog up” the review and merge pipeline, or do a lot of cursory reviews (LGTM), or worth add confusing and useless comments. So, adding value to some customer features is good, but for the sake of showing activity, it is not. Bug fixes: Someone fixes a zillion bugs? This can be great, but two questions come to mind: Why are there so many bugs in the first place? And: do all of these “bugs” need fixing? The unfortunate truth is that no software is perfect, and there is always way more to do than that there is time for. Number of hours worked: This shouldn’t need much explanation either, but hours do not equate to time well spent. Sure, if you only work 1h a day, you must be really exceptional (and not hardcore) to produce continuously high value. But if you work 14h, it does not mean you are at your most productive. Especially running out of steam/coffee. All good things need the right effort without going to extremes. Sometimes this might be more coding, and sometimes more exploration/thinking/discussing. The Value of Data-Driven Engineering Now, we are the last ones not to promote some metrics (ahem ….), but metrics are not the goal; insights into what is going on in the organization and continuous improvement loops are. Firstly, metrics are almost always poor to manage individuals. If you need metrics to understand if an employee gives you the value you are expecting, then you are already in trouble. We understand that large organizations need some sense of objectivity, but using any of the above is probably poor. Also, metrics in themselves do not solve principal issues. This brings us to the next point: Metrics are of value to highlight trends, anomalies, imbalances, and bottlenecks. This is, in particular, true for processes, workflows, and team/group aggregates. It would be unthinkable to run your ops without watching some numbers, and the same for sales or marketing. But it is always intended to improve and streamline processes and create less disruption. As such, metrics can provide great signals to manage organizational engineering productivity and remove friction in the system. For development teams, it makes sense to measure some numbers and trends. For instance: Where in the development process do we get stuck or waste time? Does our build system hold us back? Are we overloaded with reviews? Do we have QA issue? Do our sprints get re-scoped all the time in mid-air? Are there too many context switches? All these things are essential, especially for good managers to assist their teams. Managers should remove roadblocks and distractions, not micromanage lines of code. As for trends, there are some indicators of whether teams are “in the flow” or not. How are the features/PRs tracking over time? How much work do we usually get done (feature tickets, even PRs as a proxy)? Do we follow the process (reviews and approve those)? Do our security checks run? How does our build reliability perform? The question then is: Do we see spikes, anomalies, or unhealthy trends? These indicate issues with infrastructure, processes, and team health. Those warrant fixing and, in turn, create happier and more productive teams. Ensuring a smooth flow in software delivery. Reducing Friction, Not Micro-Managing The key to using metrics is to gain insights and confidence into processes, teams, and workflows that are otherwise hard to obtain. The engineering productivity objective should be to minimize any friction in the software delivery pipeline. This means the steps from planning a feature to delivering it to the customer and the reaction time to customer feedback/requests should be quick, smooth, and reliable. Any process or principle bottlenecks significantly outweigh a single contributor's shortcomings and should therefore be the major focus. Modern engineering leaders focus on the 4 Key Metrics to structure their engineering measurements to get better visibility into their teams and delivery processes. These metrics are: Velocity of delivery (how fast) Throughput of delivery (how much) Quality of delivery (how good) Impediments to delivery (how risky) Recently, a new wave of engineering intelligence platforms supports teams and their engineering managers to get the required visibility and insights to create such healthy and productive organizations. By shifting the focus away from individual performance metrics to reducing friction towards productivity goals, companies have achieved double-digit percentages of cost savings after a short period of time. We will dive deeper into this in a future article.
My journey to co-founding Kubiya.ai was triggered by the very real pain of being a DevOps leader supporting both broader organizational goals along with the day-to-day support of software engineers and others. This is my story (or at least the somewhat interesting parts) of what it was like and how I found a productive approach to managing it all. DevOps Opening Hours: 2:45 p.m. until a Quarter to 3:00 p.m. It’s really not a joke. DevOps have no time. We need to make sure everything is running smoothly from development to production and often beyond. We are busy enhancing CI/CD processes, upgrading and configuring monitoring and alerting systems, and optimizing infrastructure for both cost and security, as well as sitting in lots of meetings. But on top of all that, we need to deal with endless and oftentimes repetitive requests from developers (and others). This was exactly my experience as the head of DevOps at my previous company. The repetitive requests were not only taking up around 70% of my team’s time and energy, it had them mouthing off RTFM every time a dev would ask them a question. In Search of DevOps Self-Serve that Works So I started exploring different solutions for enabling a self-service culture in the organization to reduce the burden of the DevOps team while empowering developers to do more on the operational side. But before exploring the solutions I explored, I want to mention several things that were constantly on my plate as head of DevOps: Planning, building, and managing multiple types of pipelines for the R&D teams which included CI/CD pipelines, self service automation, and infrastructure as code (IAC) Dealing with permissions requests from different personas in the organization while keeping the security team in the loop Taking care of the onboarding and offboarding process of engineers in the company And of course the maintenance of all the different tools to accomplish those tasks While doing all of this, my team had to keep an eye on several Slack channels to answer questions from the tech organization, such as: “Where are my logs?” “Why did my pipeline fail?” “Why did my service stop responding?” Kubernetes questions, cloud questions, and more So we tried several different approaches. Internal Developer Platforms: Loads of Development Internal developer platforms, typically created and maintained by a dedicated team, are a combination of common tools and technologies that can be used by software developers for easier access and management of complex infrastructure and processes. While we considered building a developer platform, there simply was too much planning required to make this a reasonable endeavor. For starters, we had so many tools in use and with a very dynamic organization the number and types of tools were constantly changing making ongoing curation a real challenge. But aside from bringing all these tools together into a single platform, training and adoption was not realistic with a software development team singularly focused on coding the next best thing. We found ourselves struggling to decide how to create such a platform and what features should be included. Naturally we worried about creating a new kind of toil. Even if we reduced the workload coming from developer requests, embracing an internal developer platform looked like it would bring fresh pain with managing the platform lifecycle, adding new features, and as always, supporting different users. Workflow Automation Is Not So Automatic Of course our industry’s standard solution — and one that our tech organization already understood — was to automate everything possible. So, utilizing tools that our developers were already familiar with, such as Jenkins, we created automation for nearly any issue you can think of. As soon as an issue occurred, we were able to create a dedicated pipeline to solve it. The main problem was that developers didn't know where to find these workflows. And even if they knew where to find the workflow, they did not usually know which parameters to fill in. So we were back to the same routine of devs approaching us for help. Permissions were another issue. It was very risky for us to allow large groups to trigger workflows. With so much potential for chaos, deciding who should have authority to run workflows was no easy task. Even granting permissions and approvals on an ad hoc basis with the security team took a lot of time and effort. Permission lifecycles were also problematic, as offboarding a user who left the company required special handling. New workflows required adding permissions and defining who would receive those permissions. Finally, each time an existing workflow was edited to include more actions, a fresh review of both the workflow and associated permissions was required. Chatbot to the Rescue In light of the fact that developer requests came to us via a chat interface (in our case it was Slack), whether by direct messaging me or my team members, or via the on-call channel, I decided to create a chatbot or Slackbot. For permissions management, I connected our chatbot to our company’s identity provider. This allowed the Slackbot to know the role of anyone who approached it. This made it easy to create unique policies for different user roles (defined by the identity provider) in terms of consuming the operational workflows via the Slackbot. For context gathering, the Slackbot would ask the relevant questions, guiding users to provide the details needed to fill in as parameters of the different workflows that already existed for CI/CD tools like Jenkins, cloud infrastructure, and more. Besides solving the lack of domain expertise and lack of interest in operations, our Slackbot acted as a proxy with guardrails for developers. This allowed them to do what they needed without over-permissioning. Most importantly, it reduced my team workload by 70% while eliminating long delays for end users, avoiding long waits in a virtual queue. Trouble in Chatbot Paradise While this was amazing, our Slackbot was still not 100% user-friendly. Users had to choose from a static list of workflows and use predetermined words or slash commands. Our Slackbot was also unable to handle anything not included in its rule-based, canned interactions. As a result, our Dev team would be left empty-handed in cases of "out of scope" requests. The Slackbot maintenance, however, was far worse. With so many workflows to create and so many DevOps cooks in the kitchen, I could not enforce a standard programming language. Whenever one workflow broke, figuring out all the dependencies to find a fix took way too much effort. If I wanted to add a brand-new workflow, it would also require very significant effort and domain expertises. Which brought us all the way back to the same problem of more toil in managing the Slackbot. AI-Driven Virtual Assistants Exploring and experiencing the pros and cons of the various solutions led me to understand that the key to success is finding a solution that benefits both the developers AND DevOps. A system that can ask the developer questions if context is missing, transforming context gathering (which DevOps would normally have to handle) into simple conversations. Using NLU to infer user intent from a phrase fragment and offer to execute the relevant workflows is another area where AI can improve the end-user experience — so even if a developer only knows, for example, a part of the name of a cluster or service, the virtual assistant can figure out what it is that they need. This combination of all of the features of a chatbot — plus the ability to understand or learn the user's intentions (on the fly) even if it’s something new and unfamiliar — keeps workflows flowing. In addition to all this, my conversations with Kubiya.ai customers made it clear that a self-service approach needs to be tied in with security as well. Being able to easily manage user permissions both upfront in the form of policy creation for different users and groups as well as with just-in-time, ad hoc approvals is key to a successful self-serve solution. In summary, my experience building a self-serve culture has shown me that having an efficient system in place is essential for companies who want to move fast as it ensures that all parties — operations, development, security teams — can get their work done with the least amount of toil and friction.
Developer teams are no strangers to daily standup meetings. Their success in increasing collaboration and visibility has led to their adoption in different types of teams and projects. Every day the whole team has a standup agenda meeting where developers and other team members proactively align with the project and delivery goals, share progress with the team, and be on top of blockers. There are, however, developers who despise standup meetings because they are hyper-vigilant about even the most subtle indicators of unproductivity. They dislike regular standup meetings because they see no advantage to their work. Instead, they think that the daily meeting has little use to their skills and productivity, and they choose to work on projects rather than attend meetings. However, when run effectively, daily standups can be a huge factor in making significant progress in projects and eliminating blockers quickly. This is certainly a more proactive approach to leading dev teams rather than waiting for things to happen and then realizing things are going bad and having to fix them with no time in hand. Whether you are a scrum master or an engineering manager, or a developer, we have created a guide on how to run a short and effective standup and things to avoid while running standups in great detail in this blog. Keep on reading! What Occurs at a Standup Meeting Every Day? A daily standup meeting mostly lasts about 15 minutes and is often held at the beginning of the working day. Daily scrum meetings are attended by the development team, the scrum master, and the development manager in most cases. The participants vary for different teams and organizations depending on the structure of teams and how they define roles within the organization. Many teams may also not follow scrum and hence will have no scrum masters. Essentially all stakeholders involved in the day-to-day activities of a project must be present in the standup to make it effective. This also enables everyone to have clear action items after the standup. Each team member responds to the following three questions at the daily scrum: 1. What Did You Do Yesterday? This is nothing but providing an update on what progress you made yesterday on the tasks assigned to you. You shouldn’t go in too deep and too technical while providing this update. Given this is a place where most of your team will be present, it should be looked at as an opportunity to increase visibility within the team and, at the same time, help managers and other stakeholders understand the progress on different tasks. 2. What Will You Do Today? By answering this question, you are essentially laying out your plan for the day. Firstly, and importantly it brings clarity to you because when you are answering this question, you are putting in the effort to think about what should be done today. Secondly, it also makes the managers and other stakeholders understand what progress to expect in all the tasks today and helps them re-prioritize tasks if needed. 3. What Is Blocking Your Progress? Answering this will help to identify what will block the task that you are working on from going to completion or progress today. Eliminating these blockers is essential to help manage feature deliveries and to keep them on track. This helps stakeholders to gauge whether things are going on as planned and what needs to be done if they are not going on as planned. Any sort of simple realignment that needs to be done can be done here. When and Where Should You Run Daily Scrum Meetings? For teams that are working out of the same office, it is better to have standups at the same place and time every day. Ideally, it should take place in the morning so that everyone can start their days with this. But this gets tricky with remote teams post-pandemic and for teams with members from different time zones. In these cases, you may be tempted by the idea of having asynchronous standups. But we think it shouldn’t be done even though the benefits of doing so :). For the simple reason that standups give a great opportunity to increase visibility within the team and help to keep everyone in the loop. You involve everyone in decision-making by doing standups and fostering a collaborative environment within the team. Efforts should be made to work out a convenient time for everyone on the team for a standup meeting, and it should be done virtually through zoom/meet if needed. Seven Tips for Making the Most of Your Daily Standup Meetings 1. Start With Clearing Out What a Standup Meeting Is and Is Not The standup’s primary goal is to improve visibility and project flow through faster feedback. Every 24 hours, feedback boosts project velocity and allows the team to make immediate modifications to keep the project running smoothly. On the other hand, it is too late if you wait a week to get the inputs you needed seven days ago. It is supposed to be short and not meant to run more than 15-20 mins. Any longer discussion can be done with subsequent meetings with a limited set of people who are needed for the discussion. 2. Stick to the Start Time Meetings should start at the scheduled time every day, and the schedule should be strictly followed even if some team members are late. That team member could also be you as a manager. It just doesn’t make sense to have the whole team waiting on a single member, and all the more reason for you to be punctual in these meetings. Additionally, accommodate team members for whom the standup time is inconvenient and who are not able to attend standup meetings regularly due to this. 3. Prepare Your Questions To Ask During the Meeting As a manager or a scrum master, you should decide beforehand what questions you need to get answered in the standup in addition to the standup agenda. Additionally, throughout the meeting, also try to figure out blockers and how to resolve them. Furthermore, meetings post the standup is better for in-depth technical conversations. You should intervene when the discussion goes on for long and facilitate meetings post the standup for these critical discussions. 4. Keep the Meeting Interesting Since it's crucial to keep meetings brief and to the point, it's crucial for the success of the meeting that every participant participates fully and sincerely throughout. Each meeting should begin by making everyone at the meeting relaxed and included. You might employ a set of rules to choose who would speak next. This would ensure that everyone has an equal opportunity to speak while still having a good time. 5. Prioritize Workload Everyone aspires to do well. But the workload from competing initiatives frequently overwhelms team members. Daily meetings help make sure priorities are clear and accurate. A team member may be working on the incorrect thing, and important tasks may be unduly delayed if they are overburdened. Make sure team members' priorities are clear, accurate, and manageable at the daily scrum meeting. 6. Prioritize Unresolved Issues The daily scrum meeting is primarily intended to inform team members about what is being done, what needs to be done, and what obstacles prevent those tasks from being completed. Anything else has to be taken care of apart from this. Define a "parking lot" and list the problems that need to be resolved afterward. Set up a follow-up meeting with just the attendees who have a direct stake in that topic after the initial one has ended. You might keep track of the subjects that should be covered by each sub-division and require a longer discussion. The team members should have access to these "parking lots" outside the daily standup sessions so they may list the issues that need to be resolved. This keeps them present and prevents them from thinking about unrelated things during their regular standup sessions. 4. Keep the Meeting Interesting This will act as a day starter for most team members. Nothing kills the enthusiasm of team members more than a dull and boring standup meeting. Your job as a manager or scrum master is to also make sure that everyone feels motivated to complete the tasks assigned to them quickly and to collaborate with team members in the meeting. This is one of the things that, if done right, can create a close-knit and cohesive team. Three Things To Avoid in Daily Standup Some individuals may feel that standup meetings are a waste of time; however, holding effective standup meetings among teams instills team spirit, enhances productivity, and allows you to discuss challenges you're encountering in order to achieve your goals. If you go further, you'll find that this is typically a result of teams needing to use stand-up meetings effectively, which should be a systematic and quick approach to get a solid feel of what's happening with the team, coordinate work, and eliminate any obstacles. Numerous factors can cause standup meetings to derail and be badly handled. Still, over the years, we've discovered that most of these "bad habits" can be reduced to one of the crucial standup mistakes listed below. 1. Misalignment Discussing for long periods about topics that are in no way connected to the work of others. Or maybe something that concerns one colleague in a group of six people. As a result, other team members need more time to listen to unimportant information instead of concentrating on important tasks that can be time-sensitive. Additionally, if you listen to a coworker discuss something for long, for which you are not required to be there, in this case, you risk cognitively disengaging for the remainder of the standup and missing crucial information. 2. Inconvenient Meeting Time For instance, the daily scrum might be scheduled when you're coding or making progress on a difficult task, which would be disruptive or unpleasant. Coordinating schedules and accounting for calendar conflicts and time zone variances is challenging. Getting the complete crew to arrive at a standup simultaneously should be prioritized at all costs. 3. Too Lengthy People could have side chats or water cooler banter (instead of work-focused updates). Someone may begin to ramble and take five minutes to finish their thought (it's rather usual for people to offer too much information and support their actions with unnecessary details to sound more impressive). Final Thoughts Thanks to the daily standup meeting, your team and you will benefit from having common knowledge of your goals. You can ensure that your team is productive by holding this meeting to ensure everyone is working toward the same objective. Daily scrum meetings are an efficient approach to ensure that everyone on your team is committed. You will have the opportunity to point out issues and suggestions at the meeting.
A survey has found that 59% of project managers manage between 2 and 5 projects, 11% manage 6 to 10 projects, and 15% manage more than 10 projects at a time. Only 15% of project managers manage one project at a time. Managing even a single project can turn out to be an overwhelming task for project managers, leave alone running multiple projects at the same time. The task is made even more difficult when working with remote teams to get the job done. Project managers have to juggle multiple responsibilities at the same time—planning projects, creating tasks and assigning them, monitoring the team performance, checking the project progress, managing deliverables, and much more. It’s easy for project managers to lose track of vital project information amid all the chaos. The standard fields offered in some project management tools usually do not match the unique requirements of your business or workflow. How can you add additional data to tasks? How do you track and prioritize work effectively? How can you configure your projects to track what matters to you? If these questions spring up in your mind often, then it’s evident that you need a team collaboration and project management tool that offers you clarity and detail into task requirements - Custom Fields. What Are the Limitations of Standard Default Fields in a Project Management Software? There are some project management tools that do not offer users the option to add custom fields. Standard default fields do not give users the leverage to add additional information that is necessary to your project’s workflow. The fact is no two projects are alike. They differ in terms of scope, deadlines, and budget. Some projects are relatively straightforward, while others are tough and complex. Hence, the workflow of every project is different from the others, even though exceptions are always there. When it comes to project management, standard default fields do not allow users to add details that are unique to the project. Neither can you configure tasks based on project requirements. The lack of custom fields also hampers your ability to track various activities within a project. What Are Custom Fields? As the term suggests, custom fields allow you to add and store additional relevant data to your projects. Custom fields in project management software allow users to add more detail to their tasks beyond the standard default filters. With custom fields, you can add more fields to suit the unique needs of your team’s workflow. For example, in addition to default fields, you can create a field for Text, Date, Currency, Percentage, Text area, Numbers, Dropdown, or any other field that’s important to your organization, team, and workflow. This allows project managers and team members to have a granular view of different tasks and other activities across the project. What Are Different Types of Custom Fields in a Project Management Software? There are many project management tools available in the market. Only a handful of them offers users the option of custom fields. Though no two PM software offers the same options in custom fields, you can expect some common data types, which are as follows. 1. Text You can use the text field to store information of any type and size. This custom field is generally used by team members to add task descriptions or specific instructions for those who are assigned to the task. 2. Numbers This custom field is meant specifically for adding and storing numeric data. It is useful for storing figures like IP addresses, logged working hours, tracking numbers, contact numbers, etc. 3. Percentage The percentage custom field is usually added to denote the progress of tasks in the form of percentage data. For example, if the task is in progress, it would be denoted as 50%. 4. Tags Tags are like labels. You can create and add them and use these tags again and again to organize and track your work. You can also customize them using different color codes. 5. Date This custom field can be created and added to store start and due dates, estimated dates, and set dates for tasks. 6. Dropdown Dropdown custom fields can be used to create and add a list of options for users to select from. You can add any number of options and color code them for a better view. How To Use Custom Fields in a Project Management Software Whether you’re a project manager or a team member, adding custom fields in project management software is as easy as it can get. You must add custom fields to selected tasks per your project workflow requirements. This will allow easier access, filtering, and sorting of tasks. Using custom fields, you can be more descriptive about your tasks. When you add fields to tasks, these automatically get added as sections when tasks are viewed in a table view. Be it resource allocation, daily task management, or work prioritization, you can easily track anything within your project with the help of this innovative feature. Some examples of custom field applications are as follows: Budget Management — You can add custom fields to manage and track project costs besides restricting the visibility of your sensitive financial data to only authorized users. Task Progress — Custom fields allow you to be more descriptive about task statuses. Apart from standard “In-progress,” “Pending,” or “Finished Statuses,” you can choose to display task progress in the form of a percentage or by adding insightful options like Ideas, Approval, Review, Submitted, Published, Declined, etc. Categorization Of Tasks — You can classify your tasks into different categories, which makes it easy to search and filter them. You can also prioritize tasks according to project requirements. Add Tags — You can add tags to certain tasks using Custom Fields. Tags work like labels, which is an effective way to categorize, organize, and prioritize your work. Create Dropdown — You can create dropdown menus and different options for team members to choose from. For example, you can create a dropdown and add options for users to choose from, like Stage 1, Stage 2, Stage 3, etc. Multiple Uses — The main advantage of custom fields is that these can be edited according to your project requirements and store pivotal information. The application of custom fields is not limited to specific project details. For example, the number field can be used to add, store, and track numerical data like IP addresses, payroll, ticket numbers, budget, costs, and more. Hence, every custom field can be used as per your workflow and project requirements. The Final Word Custom fields bring flexibility and customizability to project management. There are many project management tools that offer project teams default project management processes, which leaves them with little to no room for editing and customizing things. Custom fields enable users to work on different projects without any confusion. When you choose a project management software for planning, organizing, and executing projects efficiently, make sure it does offer you the much-required feature — custom fields.
The volume of activity taking place in engineering teams can be mind-boggling, making engineering teams rather difficult to manage. Successful engineering managers, however, are adept at steering their teams to success by tactfully monitoring and using software metrics. Software metrics enable visibility, and acquiring a complete understanding of the software delivery process from concept to production can help in the discovery of bottlenecks or process concerns that, when solved or optimized, can enhance the engineering team's health and efficiency. Code Churn is one such metric that managers use to analyze their team's progress. Monitoring code churn patterns across the development lifecycle can enable managers to identify when an engineer is stuck or struggling, when there are concerns with external stakeholders or if an approaching deadline might be at risk. What Is Code Churn? Code churn, also known as code rework, is when a developer deletes or rewrites their own code, shortly after it has been composed. Code churn can be good or bad depending on when and why it is taking place. For example, consider a scenario wherein a large portion of your team's code churn occurs close to delivery. This might be due to any number of factors, perhaps outside of your team’s control. When managers have access to view only the metric without context, it becomes difficult to judge the nature, cause, and consequences of the problem. Thus, code churn is worth delving into in-depth since identifying a mistake during the design process is significantly less expensive than catching it during maintenance. Here are some common causes of code churn and some possible countermeasures: Causes of Code Churn In many scenarios, code churn is unavoidable. Redesigns, prototypes, and proofs-of-concept are all examples of situations when huge sections of code are expected to be rewritten, and these levels will differ depending on the developer, the sort of project they are working on, and where the team is at in the software development lifecycle. So, if you find exceptionally high churn, assess if it's normal or whether something is amiss. High levels of code churn usually reveal critical issues outside of the conventional development process; it might be that the team's product owner is supplying unclear specifications, or the developer is facing difficulties. Addressing these issues will assist to reduce friction in the development process, allowing the team to spend less time waiting on others or dealing with confusing specs and more time concentrating on the main challenges at hand. Some of the most prevalent workflows and dynamics that can lead to exceptionally high amounts of code churn are: Prototyping and complex tasks Ambiguous project and task requirements Scope creep Questing for perfect code Burnout and retention/turnover issues Prototyping, R&D, and Exploratory Churn It is common across development cycles that a newly composed piece of code often goes through multiple changes. The volume of code changed and how often the code is changed in a short period of time can vary due to several factors. When a developer gets immersed in exploratory projects, he or she may make compromises in code standards in order to achieve a faster proof of concept, only to refine it later after an ideal solution has been found. Although there is more code churn in the short term, the approach is productive as it helps the developer to rapidly explore new ideas, thus proving beneficial. Redesigns, prototypes, and proofs-of-concept are all instances when huge sections of code are likely to be rewritten. Prototyping is a natural and healthy trend; therefore, expect things to be headed in the right direction as long as code churn decreases down the development lifetime. It's OK to allow developers the time and space to research and develop at this stage. However, if the pattern continues for an exceptionally long period of time, beyond what is expected to occur for the current task, it might indicate that the developer failed to completely comprehend specific components or the entire problem, or the problem might be more complex than expected. To recognize such a situation, become familiar with the developer's normal level of code churn and keep a watch out for developers’ churn patterns. However, if the pattern continues for an exceptionally long period of time, beyond what is expected to occur for the current task, it might indicate that the developer failed to completely comprehend specific components or the entire problem, or the problem might be more complex than expected. To recognize such a situation, become familiar with the developer's normal level of code churn and keep a watch out for developers’ churn patterns. Countermeasures: A developed set of principles and work processes improve any software development team: Make sure the amount of time developers spend prototyping is reasonable for the level of business risk and the value you expect from the product. Set up a pair programming session with a more senior engineer if the problem proves to be more difficult than planned, or if a developer is working on a new set or domain of challenges. Ensure that developers do not create custom solutions for problems that can be handled by existing resources unless the project requirements specify otherwise Scope Creep Scope creep is a pattern in which the scope of a project grows or changes after it has been implemented. Scope creep is often, but not always, gradual and hence undetectable. Adding features in the middle of a project necessitates a significant amount of unanticipated labor. Out-of-scope tasks can occur even in the most well-defined projects. As a manager, you must keep an eye out for runaway scenarios in which engineers are expected to bear an unjustified rise in scope. As features are completed, the challenge that a team is attempting to solve should become smaller. Often, an indicator of scope creep is characterized by a sudden increase in churn levels at the end of a development life cycle that isn't always caused by a code review, thus indicating the fact that maybe some new features or requirements have arrived during the later stages of the project. Countermeasures: Requests for modifications can happen at any time, but many of them can be avoided. Examine and optimize the requirements gathering process from external stakeholders. This will avoid scope creep becoming a pattern across sprints. Scope creep is caused by a lack of preparation and attention throughout the design process. It is not the engineer's obligation to take on the effort that results from incorrect specifications. Hence it is important that you make it clear to those in charge of pushing a poorly planned project through that it is not acceptable. Before beginning development, share any relevant discoveries with your customer and their specialists to determine whether, how, and when to include extra requirements. Perform a brief search to check if there's anything in the news that might affect the project (new technology, legislation, critical technology partners going out of business, etc.). Ambiguous Software Requirements Defining specific software requirements is the beginning of a software development process and the guarantee of its consistency in later stages. During this phase the Software Requirements Specification (SRS) document should clearly lay down the foundations and guidelines that the parties involved in the project should follow. Inconsistencies and ambiguities in the SRS document spread to subsequent phases of software development, compromising the quality of the final product. When a Product Owner gives partial or incomplete requirements, additional engineering effort is spent filling in the gaps, or the developer is forced to work with unclear specifications or to decode using their best reasonable estimate. Some of those assumptions will undoubtedly be erroneous, resulting in increased churn. The amount of tolerance for ambiguity in requirements varies depending on the experience of the engineers implementing the project. In comparison to an established team of developers, a team that comprises mostly fresh members will ultimately demand tighter direction. Another common occurrence under this subject matter is when the Product Owner makes revisions to their demands after the implementation has begun which eventually leads to missed deadlines. The same product owner's reoccurring scope creep tends to indicate this pattern. On the back of the sprint, you can observe a substantial increase in code churn that wasn't driven by code review. Countermeasures: Code churn caused by ambiguity is problematic, although it may be avoided by: In most cases, the Product Owner's manager should be in charge of managing the problem, they could just provide instructions on any areas the individual tends to neglect when writing and creating specs. Check with your developers to see whether they believe the objectives are well-defined. Maybe conducting standup meetings to verify the same. Questing for Perfect Code Oftentimes, after resolving the issues brought up during the review process, the developer begins giving their code the last polish, and in the process, new faults surface, creating delays. This pattern is defined by heavy churn in the mid-late phases of a sprint or project after the work is ready for production. With a few developers, this is a rather constant pattern. It's simple to see in their code churn history, and it might also be reflected in a pattern of work delays. The major reason is when an engineer's definition of "good enough" differs from the company's, or when an engineer makes enhancements that are well above what is required from a commercial standpoint without providing significant value. If there is a lot of churn leading up to a release, the release may be impacted. Excessive reworking of code shortly before a deadline might indicate that the release should be postponed. Countermeasures: For some engineers, perfectionism is a difficult practice to overcome, and they must be progressively trained away from it. Here are a few techniques to keep things under control: By establishing a shared understanding of what constitutes "good" code By asking a more senior engineer to assess the same code in the context of the project. By analyzing whether the work that was originally presented met team standards, and if the new work is a consequence of feedback from the review process that resulted in a significant improvement to the original code. Burnout and Turnover Burnout or engineer dissatisfaction could be indicated by a high level of churn combined with indicators from several performance metrics such as responsiveness, active hours, code efficiency, and low throughput of your developer over an extended period of time. This may arise as a result of a work pattern known as "Bit Twiddling," in which an engineer devotes his or her whole attention to a particular section of the codebase for an extended period of time, making only minor modifications here and there. It's like putting together a jigsaw puzzle and realizing you're not making any progress — and it typically happens because the engineer doesn't completely comprehend the problem or the context in which the modification is being made. Countermeasures: On the job, software developers are in danger of burnout. Everyone handles stress differently, but the long-term effects might include developers becoming disinterested, failing to show up for work, considering job changes, and, well, it can get worse. When discovered early enough, burnout may be swiftly reversed, therefore practice the following to keep all of your developers intact: Provide regular feedback to developers and show appreciation for their efforts. Unwanted work should be outsourced or rotated so that no one is trapped with a task they despise. Assign new tickets and projects which would help enable the developer to explore new and interesting areas of the codebases.
Project managers are important members of any team. They work tirelessly to ensure that projects are completed on time, within budget, and to the best possible standards. However, there are a few objectives that can help improve performance as a project manager. This list includes objectives such as developing and implementing project plans, setting priorities, and managing communication and stakeholder relationships. By following these objectives, project managers can guarantee that their projects are successful and meet the needs of their teams and clients. What Are Project Managers’ Objectives and Goals? Project managers are important members of any team. They work tirelessly to ensure that projects are completed on time, within budget, and to the best possible standards. However, there are a few objectives that can help improve the performance of the project manager to manage the team and organize the workflows. This list includes objectives such as developing and implementing project plans, setting priorities, and managing communication and stakeholder relationships. By following these objectives, project managers can guarantee that their projects are successful and meet the needs of their teams and clients. Why Do You Need to Set Up Project Manager Objectives and Goals? Project management can be a complex and time-consuming process. If you’re not careful, it can easily become bogged down in details and paperwork. That’s why it’s important to have clear objectives and goals set from the outset so that the project can move forward smoothly and without any unforeseen delays. Here are some reasons why it’s essential to have project manager objectives and goals in place. Top 10 Project Manager Objectives to Improve Performance 1. Meet Deadlines and Finish Projects on Time As a project manager, you need to be able to meet deadlines and finish projects on time. This is important not only for the sake of your team but also for the sake of the project itself. When you set deadlines, make sure that they’re achievable given the resources that you have available. Make sure that all stakeholders are on board with your timeline and understand what’s expected of them. And finally, make sure that you’re constantly monitoring the progress of your project and adjusting as necessary. This way, you’ll be able to achieve your project goals on time and without any major glitches. 2. Control Budget As a project manager, you need to be able to control and manage your budget on time in order to meet your objectives. There are a few things that you can do to achieve this: Set realistic deadlines for each stage of the project. This will help you plan your resources accordingly and avoid any delays or extra expenses. Make sure that all stakeholders are kept up to date with the project’s progress so that they know what’s expected of them. This will ensure that everyone is working towards the same goal and avoids any potential conflict or misunderstandings. Monitor the budget closely throughout the project so that you can make necessary adjustments as needed. This will ensure that you stay within your allocated budget while still achieving your desired outcomes. 3. Improve Team Collaboration and Communication There are a few ways that you can improve team collaboration and communication. One way is to establish clear and concise goals for the team, and then make sure everyone understands what they’re supposed to be doing in order to reach those goals. This will help to ensure that everyone is on the same page and working towards the same goal. Another way is to create a team culture that values collaboration and communication. This means creating an environment where people feel comfortable speaking up, sharing their ideas, and asking questions. It also means fostering trust among team members, so that they feel safe sharing confidential information with each other. 4. Manage Stakeholder’s Expectations Creating a successful project depends on managing stakeholders’ expectations. Stakeholders are all the people or groups who have a vested interest in your project — whether they’re directly involved in it or not. They can be customers, employees, partners, or others. You need to be able to manage stakeholders’ expectations in order to keep them happy and committed to your project. This means understanding what they want and need from your project, as well as how you can fulfill their needs while still meeting your own objectives. It also means being able to communicate with them effectively so that they understand what’s going on and feel like they’re a part of it. Managing stakeholders’ expectations is a difficult task, but it’s essential if you want your project to succeed. If you master it, then you’ll be able to build trust and loyalty among your team members – two key ingredients for any successful venture. 5. Improve Team’s Productivity and Effectiveness One way you can do this is by training your team members on the principles of effective communication. This will help them to better understand each other and resolve conflicts peacefully. It will also help them to work together more effectively, as they’ll be able to read each other’s minds. Another way to improve team productivity is by providing clear and concise instructions. This will help your team members know what they’re supposed to do and avoid any needless confusion or hesitation. It will also reduce the amount of time it takes them to complete their tasks, which in turn will boost their morale and motivation. 6. Create a Data-Driven Culture A data-driven culture is one in which everyone is conscious of the data that they’re collecting and how it can be used to improve their work. This means that everyone is constantly looking for ways to gather more data and use it in more effective ways. To create a data-driven culture, you need to focus on four key areas: information gathering, information analysis, decision-making, and communication. In information gathering, you need to ensure that all members of your team are actively collecting information from all sources possible. This includes both structured and unstructured data, as well as social media posts and other online content. You also need to make sure that this data is properly stored and accessible for later use. 7. Execute High-Impact Projects Projects that are high-impact are often the ones that require a lot of dedication and effort from both the project team and the individual members. They’re also the type of projects that can have a big impact on your career or business. The best way to ensure that your projects are high-impact is to make sure that you have a clear vision for what you want them to achieve. This will help you prioritize the tasks and resources necessary to bring it about. You also need to set timelines and deadlines, as well as measure progress regularly so you know when adjustments need to be made. Make sure that everyone on your project team is working towards the same goal, and be willing to delegate tasks if it means completing the project faster. And lastly, don’t be afraid to ask for help when needed — even if it means taking on some extra work yourself. 8. Mitigate Risks Proactively There are a number of ways in which you can mitigate the risks associated with your business — and this is an essential part of any risk management strategy. One way to do this is to keep track of all the risks that your business poses. This means knowing what could go wrong and how likely each scenario is. This can help you make informed decisions about how to manage those risks and protect yourself from potential damage. You can also implement risk management techniques like risk assessment, risk management, and risk communication. These help you identify, assess, prioritize, control, and monitor your risks so that they don’t end up hurting your business or putting people at risk. In addition, you need to have a plan for when things go wrong – this includes setting up procedures for responding to incidents and crises, as well as ensuring that your insurance policies are up-to-date and cover all the risks that your business poses. 9. Improve Productivity Project managers are responsible for making sure that projects get completed on time and to the required standard. They also need to ensure that the projects are managed efficiently and that all stakeholders are kept up-to-date with progress. To improve productivity, there are a few things that project managers can do. The first thing is to establish clear goals for each project and make sure that deadlines are met. This will help keep everyone on track and ensure that everyone is working towards the same objective. Another way to improve productivity is by using effective communication tools. This means ensuring that all stakeholders are kept up-to-date with progress, changes, and relevant information. It also means being able to convey complex information in an easily understandable format. 10. Utilize Project’s Resources Optimally Project managers are responsible for ensuring that the resources allocated to a project are used in the most efficient way possible. This means that they need to make sure that all the necessary resources are available at the right time and in the right form. One of the most important ways that a project manager can optimize resource use is by using effective communication channels. They need to be able to send clear and timely updates so that everyone involved knows what’s going on and what needs to be done. Additionally, they should make sure that all team members understand their individual roles and responsibilities, so that everyone is working towards the same goal. Conclusion By now, you know that getting a good project manager is the key to success. Teams and companies with enough resources are able to use their expertise on the right person who can lead them through every obstacle in their way. With such a track record, it’s clear that managing people is not an easy task for this profession but it can also be made easy if you have the right objectives in place. Keep reading through these 10 objectives and try using some of them when hiring new PMs!
Feedback is one of the most valuable tools to support people and company growth. What is feedback? It is any information about the product, workplace, company culture, team, workmates, or managers used as a basis for improvement. The feedback comes from many sources, but in this article, we focus on feedback between engineers and their engineering managers. The feedback goals, frequency, and methodology to achieve them are good indicators of the company's culture. For example, there are many companies where the goals are only focused on performance delivery and not on the growth of the people's career path or skills. Most of the companies where I have worked had annual performance reviews. The goal of this meeting was to give me feedback about the project goals of the last year and sometimes it seems the justification to give you a promotion or why not. In this article, we will review some of the concepts most important to get good feedback. Positive and Negative Feedback In either case, the feedback is a tool to improve; therefore, the feedback has to be always a constructive message. Even in the worst cases, such as in regard to people who are fired from the company or moved to another squad, the feedback should be more constructive than ever. It's especially in the worst situations when people need support and feedback on what went wrong and what they need to improve. We should not misunderstand constructive feedback by not providing an honest message. Feedback Bidirectional The feedback has to be company-wide and bidirectional. One of the tools that we have to get feedback are one-to-ones. These should not only be with the direct engineering manager, but also with others such as "skip-level 1:1s" with the director, the head of engineering, etc. In the case of the engineering manager one-to-ones, the frequency depends on the need of each engineer; but at least 45 minutes every two weeks. These meetings must be focused on the engineer's needs. However, from my experience, these chats tend to be about global feedback, personal issues, and his/her professional growth. Rather, they are rarely about what the engineering manager needs to improve in order to help them: being more comfortable in the team, achieving the goals, or being more efficient. This is something that worries me a lot, and I have discussed it with many peers and engineers about what could be the reason. Some of them feel that this feedback is not well received by their managers, that it's simply not listened to, of no interest to them, or we could go so far as to say that they feel it may even affect their salary reviews or promotions. As engineering managers, we need to understand that for the feedback to be constructive, the first step is "to learn how to receive feedback." This begins with some of the following activities: Out ego: We are not perfect. There are always skills to improve. Continuous improvement and critical thinking about ourselves We also make mistakes every day that could possibly have a negative impact. There are always problems and challenges to be faced and you are not alone in this. Your team, engineering managers, and the company can help you to overcome this together as a team. Our goal is to support our teams to be better and achieve their objectives. Informal vs Formal There are two types of feedback: Formal feedback: Usually through meetings and tools such as surveys; this is the most common type of feedback in companies and is very necessary. Informal feedback: It is the spontaneous feedback that comes out of conversations between people, sometimes at coffee hour, in a casual encounter in the hallway, or over a few beers with colleagues. The best feedback is the one that takes place in an environment of trust, and that is probably why informal feedback is perhaps more valuable, and at the same time, more complicated to analyze. Honesty Feedback has to be honest, and always has to be constructive. However, constructive does not mean sweetening the reality. There are many people and engineering managers who have difficulties in sharing what aspects we have to improve. The most important thing is to understand that we are not helping anyone with this type of attitude, but rather doing the opposite. People can't improve if they don't know what they need to improve. Being honest does not mean being rude. Every person is different and each has a different way of communicating. As a manager, we must adapt to each personality type of our engineers. Tunnel Vision Every person has cognitive distortions that make them see the world in a different way based on their experience, culture, personality, or training. In the end, each person's vision is always subjective and partly unrealistic. Black-and-white thinking Jumping to conclusions Overgeneralization Labeling Disqualifying the positive For these reasons, these are some best practices to apply: Skip-level 1:1 meetings quarterly with directors or the head of engineering: Feedback should not only be to the direct manager to minimize subjectivity. On important issues, always gather several opinions from other engineering managers without affecting the confidentiality or trust of the engineers. Provide other points of view and alternatives. Challenge our/their thoughts and check their veracity. Look for alternative ways of thinking. Evaluating and rating feedback based on the person giving it and the topic Correlating feedback from all stakeholders is a must in order to find points in common and those where there are discrepancies. Points in common: They usually are the most realistic points to improve. Topics with very different points of view: Sometimes these points can affect the team's dynamics or can be very complex issues. The Value of This Information Companies usually take main decisions and strategic decisions based on their business goals, sales, number of users, or feedback from customers. But the feedback from the engineers is also important and allows us to correlate the global view of the organization and analyze what is coming in the future. I feel that in many organizations, even though there are many channels to give feedback, this feedback is not analyzed or considered when taking action. I have always believed that a company's greatest asset is its employees. This does not mean that they are always right or that the organization has to make the decisions recommended by them. Engineers must be listened to. This does not mean that every feedback or recommendation will be applied; this means that we are analyzing their feedback and in combination with other indicators, a decision will be taken. This will be shared with them. What needs to be noted is that not every decision can be explained to them and can be the object of a debate, as this is something that can gravely affect the agility of a company or can even paralyze it. Continuous Feedback The difference between feedback and continuous feedback is the frequency. Annual feedback doesn't add any value and can have a negative impact on the company and the engineers. Frequency makes it possible to be more agile in reacting to situations that affect individuals and the team. As a manager, we must always have time available during the day to talk to the engineers when needed. Conclusions The feedback must be promoted as part of the company's culture. If not, it will never be effective. The feedback culture requires constant efforts over the years, no egos, and an environment that promotes trust and honesty in the organization. It is one of the most challenging and complex goals to achieve in an organization and at the same time one of the keys to success. Continuous improvement as an organization, team, or individual begins with feedback.
Engineering teams are the core of every software development company. For some, establishing an engineering team may seem a challenge but for many keeping a motivational and collaborative atmosphere is a desired goal for the long term. I had a chance to interview one of the successful CEOs of a new startup who has been successful in engineering management. He is going to share with us the secret behind his management style. My guest this week in the Proof Of Concept was Thomas Hansen, founder of Aista, who has experience in software development for over two decades. He is an exceptional founder who is developing his platform while managing his team and growing his startup. It's a fantastic talk, and I invite you to watch it. Let’s look at his take on the manager role in building a team of engineers and managing the company. Engineering management requires a manager responsible for managing software development assignments or projects, but it is more than just handling technical issues and testing code. First and foremost, they have to be able to influence the abilities of their team of software engineers so that they deliver their full potential. Skills Required for Engineering Manager You may be a top-class coder, but being a manager requires a set of different qualities. The engineering manager must know all about software and coding. If you have no coding or software development skills, you cannot develop a competent software team, let alone software. Moreover, the manager must also have the following skills: Software-related academic qualifications Ability to listen to the team Have no trouble with micromanagement Accept your faults Trust the team Delegate authority to the team Think of bigger goals Lead from the front and take responsibility Q: How Do You Work With the New Team To Derive Software? As an engineer manager, you must practice many managerial skills to become a successful manager and lead the team toward success. Here are a few tips and tricks to efficiently manage a team of engineers. One of the most challenging things about dealing with a team is entrusting them with your project and giving the members some space. Initially, it may sound excruciating for you to let others handle your software and code it. But once you have checked their work and it's good, do not unnecessarily poke in their work. Remember that a single man cannot run the company; it is not a one-person show. You don’t have to spoon-feed them or impose your opinion all the time. You, as a manager, have to accept that they can do the job differently, but that is good for the team. It is called micromanagement. Managers may encounter this situation and get confused with mixed feelings about keeping all the burden and letting go. The best thing you can do to accept micromanagement is to ask an open-ended question to your team. You may come across some better answers between discussions than what you have in mind. So you can let go of micromanagement syndrome by accepting some of your team's best ideas and opinions. When you accept your team, its work, and competence, you are now the manager and no longer the developer you once were. Additionally, the delegation of authority also helps people to get more collaborative. The collaborative approach boosts the work environment and overall productivity of the team. For delegation, you have to trust the decision and abilities of your team. Trust is critical for the team to work collaboratively. Lastly, encourage the team to be creative by giving them room for mistakes. The first thing you can do is accept your own mistakes in front of the team. It will enable them to follow you and be creative and innovative. Taking responsibility for their mistakes and letting them do what they feel is correct also inculcates a sense of responsibility in them. When you have successfully delegated authority and get good at micromanagement, at this stage as a manager, you can think of the following big goals or steps while your team works on the current tasks. Q: Do Teams Need an Engineer Manager for Better Performance? Flat management has a vision but lacks somebody who coaches them and reassures them to be innovative. On the other hand, having an engineer manager makes things easier for the team. If the team has a manager who backs them, they look up to the manager's vision and rest assured that they can get innovative. He is also someone who can coach his team members for successful collaboration. The Secret to a Happy Engineering Team Managers can do many things to keep the team contented. But one of the best things managers can do is to acknowledge them for their work. Don’t let even a minor task go unacknowledged if it is praiseworthy. If you praise the team member in front of others, it is even more helpful in boosting their self-confidence and becoming happy. Wrap Up The engineer manager post is a kind of journey, and many people come across different teams and organizations that may require a different approach. However, generally room for mistakes, trust, acknowledgment, delegation, and micromanagement go a long way in building creativity in the team of engineers and the company's success.
Today, I'd like to cover the weekly life of a project manager. When I'm managing a project, these are the things I do every week: Identify the next milestone. Do you have a goal that is less than a month away? If not, make one up as soon as you can. Talk about the next milestone in every meeting with the team. Update your project plan. Schedule an hour or two every Friday to review and update your project plan. Update your risk registry. During your project planning time, update your risk registry. Send a weekly project update. After updating the project plan and risk registry, I send out an update that summarizes where things are with all the projects for which I'm responsible. Putting these things together will often require meetings or conversations, but having a concrete idea of what you're delivering each week can make it more clear what to focus on. 1. Identify the Next Milestone People work best when they're working towards a goal that is close and easy to wrap their minds around. They are engaged, more productive, and more effective when working on a milestone that is less than a month away. This also cleaves complexity into a chunk you can manage. People can reason about that much work. They work more effectively towards it. Most weeks, you should already have the next milestone identified. Fantastic! However, you'll often be close to finishing that milestone, things will shift in a project, or the project won't be broken down enough to have a milestone that is soon enough. Why a month, as opposed to something sooner or later? The short answer is that this is what I've seen both with my own experience and with evidence from some limited data I've seen. You can read more about this in my post on milestones, not projects. I recommend getting the product manager, designer, and people who have thought the most about the technical contours of the project in a room, and telling them you'd like to identify a milestone: "What would the best milestone be that is less than a month away? Let's come up with a few possibilities, and choose the one we like best." Start with the constraint that you always need a milestone that is less than a month away. If you don't have one, or you're about to finish a milestone, make sure you have the next milestone identified. Refer to that milestones post to learn more about the art of breaking up projects, and also remember that this is a real skill that takes time and practice to develop. 2. Update Your Project Plan I book time every week to update my projects. I review the project plan and make sure it reflects my current thinking. I ask myself if it still seems realistic. I think through the rest of the project and think about potential sources of delay and risk. Wishful thinking is your enemy. Look at everything from a skeptical perspective. For some people, this is natural, and for others, it requires practice. You will often need information from others in order to update the project plan. I usually schedule a weekly meeting per team, or per project. At this meeting, I have the main leaders present, walk them through the next couple of weeks in detail, show them my current thinking on the project plan, and ask them to critique it. I then go through further out into the future, but with a little less fidelity the further out we get. Usually, I invite someone representing product, technical leadership, and design. Try to keep these meetings pretty high level. You want them to not be a huge waste of time for the participants. I often find it best to join this activity into a meeting that has a larger purpose. For example, a local team's leadership meeting might cover this in 5-10 minutes every week, but the majority of our time we might discuss other matters, like the things we're concerned about or need to improve. One anti-pattern for project managers is that you can get into a habit of pinging people for information all the time. This is annoying at best. Make it inexpensive for people to keep you informed. And also encourage people to surface what they're observing, so you don't have to update them. Switching communication to push from pull is preferable. What Should the Project Plan Look Like? I make project plans that are week by week. Each week has a couple of bullet points. The bullet points are things we plan to demo that week. The demos should include technical demos, but the description of what we will deliver should be as customer-focused as possible. I also add time-based events that are relevant to the delivery of the project. For example, vacation time, on-call schedules, and offsites. The goal for your project plan is to not be more specific that a couple of bullet points. You want a plan that is easy to change. The more specified your project is, the more expensive it is to alter it. A good project plan should be a tool for discussion and one that encourages change rather than discourages it. When I see lots of project artifacts, and things that require updating, I get skeptical. Gantt charts communicate effectively but are often a sign the underlying data is hard to change. One thing to watch out for is many engineering teams work on a person per project. The more you can use the team as a unit of delivery for your projects, the better. This is a deeper topic, so I won't go into a lot of detail now, but in general, when I see project plans that specify what each person is doing, I view that as a sign that the project is unnecessarily brittle, and a team that is overly specializing, and not doing enough knowledge sharing. This can be appropriate for small companies, but otherwise, I tend to discourage it. If I see the fractional allocation of "resources" in a project, I typically scream, take a lighter out of my bag, set my hair on fire, and run out of the room. The fewer projects you're managing, the better you'll do with them, so that's another argument for teams focusing on fewer projects. People ask if you need a week-by-week project plan if you're on a team that has two-week-long sprints. Of course, it is up to you, but I would do it week by week. Otherwise, you have very little visibility into whether things are on course or not. If I were doing it on a two-week-long sprint cadence I would tell the team that this is a plan showing whether or not we could demo this by Friday every week. 3. What Should Your Risk Registry Look Like? As you update your project plans, you should also ask yourself what could go wrong. Here are a couple of ways to ask yourself, or others, questions that will help you plan better: What is most likely to go wrong with this project? What projects have been similar to this in the past? What challenges did we have with them? What's the worst-case thing that could happen on this project that seems like it could actually happen? If we had to bet this month's salary on this project going well, what are things we would be worrying about right now? Risk management is a balancing act. You don't want to overinvest in many of your risks, but you do want to think through them. After you come up with new risks, list them as bullet points in your risk registry. For each risk, you or your leadership group should determine if you want to take any action to mitigate that risk. Next to your risk registry, list your plan next to each or write down, "accept risk." If your leadership group is functioning well, you can have rational discussions about the risks, and the cost to mitigate the risks. I suggest when you introduce a risk registry, you have a conversation about the costs of mitigation and be sure to have conversations about not just how you'll mitigate risk, but whether you even want to. 4. Write a Weekly Project Update After updating my project plan and risk registry, I have a good idea of the current state of the project. Now I help the people around me by sharing that state, in as concise a format as possible. The aim of a weekly project update is not to share everything about the project. It's also not to show how great your team is. When you approach project updates from either of those perspectives, your writing becomes excruciating to read. Instead, you should focus on the needs of your reader, and give them just enough information that they can come to you if they need, to have a longer conversation. This tweet summarized a lot of the things I've learned over the years about writing concise, readable updates. It also features some wonderful examples, so I strongly recommend reading through it: One thing I'd like to emphasize is that you should come across as a neutral party: objective, upfront about risk, and exposing things without bias. Your update should include a link to the source of the information: the project plan, risk registry, and a link to demo the current state of the project. After you write your update, send it to your stakeholders. You can use a mailing list or a channel in Slack. You want to make it easy for new people to follow the information. You'll probably be surprised who finds it useful. You might find other parts of the company that find your updates useful. These updates help the people around you to be effective. Your manager will be informed about the state of the project, so they can represent your work in meetings (you have no idea how helpful this is for them). Other teams that depend on you won't have to contact you to get updates. It provides a very nice communication scaffold. You may even get thank you notes! Incidentally, these updates help demonstrate your ability to manage the project. I find the project updates to be a good forcing function for doing the rest of the project management. Knowing that I have to send out my weekly update forces me to take the time to do everything else. Ideally, the update should be just a tweet or two in length. You don't need a lot of detail: people can talk with you if they have questions. Thank You I've had a long history with project management, even writing project management software in the past, but Bjorn Freeman-Benson really hammered into me the details of how to write a good update. He acted as an editor, training me each week on how to do better.
In the past year or so, people started writing about the phenomenon of quiet quitting. It isn’t new, but it somehow became trendy as more people are doing this. This isn’t something I care about as much. People often describe me as a workaholic, which is pretty accurate, and I love it. But I totally get the problem that triggers quiet quitting and its root is in a lack of loyalty. A cursory reader might think I’m blaming the employee for lack of loyalty — I am. But loyalty is a two-way street and some employees are merely reflecting something that we’ve been conditioned to accept for the past few decades. Back in the days when I formed my consulting company and later on Codename One, I read pretty much every business management book I could find. Back in 2014, I read a rare book in that genre where I cringed at every page. I don’t enjoy reading business management books. This isn’t a pleasant read. But here I literally cringed at so much of the sage advice from Mr. Horowitz. Notice I don’t say the advice is wrong or even that it’s bad. I don’t think he’s a bad person for giving it either. I think this advice produces its exact desired intention, fast growth at any cost. The fuel for this fast growth is people. They get burned and cast aside like the fumes of a jet engine. The expectation is fast turnover, by the time the person is “burned out” we’ll replace them anyway with a fresh “expert” to fit the current stage of the company. This approach to building companies wildly over emphasizes transferable skills while under evaluating pretty much everything else. Company Values Another book I read well before was “Built to Last.” It has its own faults and problems, but that’s a different story. One of the core ideas explored in the book was the idea of corporate values that are listed as a set of principles. They claim that great companies had codified their core values early on. This supposedly shaped their corporate DNA and helped them become great. Back when I read it, I always felt this was a load of BS. I don’t subscribe to such frivolous management drivel, but I’ve started rethinking that recently. I was always in the camp of interviewing people as a conversation and a process. Hiring “good people” is more about finding the right “fit” for the specific team. But how do we know we all share compatible values? Even if we don’t, how do we align so at least “on the job” we can act consistently? This came back to me recently. I think such values are indeed a crucial piece in shaping the right team. I know which value would be the first on my list when I form my next company: Loyalty. Corporate Loyalty: Not That Way Jobs often expect loyalty from us. I try to give it as much as reasonably possible. It doesn’t mean I don’t have open to other options on LinkedIn. It doesn’t mean I don’t demand a raise and imply I’ll walk when I think I deserve one. Those don’t imply disloyalty in any way. I won’t go to work for a direct competitor. I also wouldn’t want to work for a company that would pouch me as a direct competitor. This is the point I’m getting at. Loyalty is given. Not asked. A company needs to declare loyalty as its value, not one it demands from the employees; e.g., when an employee makes a mistake — even a big one. That employee shouldn’t be fired instantly. Hell, instant firings shouldn’t be a thing. A single manager or even the CEO shouldn’t have the right. Someone having a bad day shouldn’t impact their future livelihood. A corporation should stand behind an employee who made a mistake. More than once. People need to feel secure in their jobs. When a corporation just blindly fires and hires they end up with jaded employees who don’t care. This affects the product and the company in a way that no corporate nonsense can wash away. The customers end up with an inferior service or product. A disposable employee or one that’s just stepping through, won’t bother. Therefore, loyalty to employees should outweigh the loyalty to the customers. The customer doesn’t always come first. We need to tone that down. We can’t service the customer if our house isn’t in order. By backing our employees, these employees will give the customer better service and a better product. I worked at very large corporations. In most cases, I had managers that represented these values and I enjoyed working with them. It’s an uncommon experience compared to the typical corporate nonsense. But the thing about corporations is the constant restructuring — you can’t develop trust and good working conditions without building that culture from the top-down. It’s also hard to plug this culture into a company that’s already too big. Quiet Quitting I get why people “quiet quit.” Why show loyalty to a company that will fire you in an instant? Why go “above and beyond” when the company won’t do the same for you? I think most people just looked for a new job and would switch jobs. In normal times, that’s the right thing to do. But in these times, starting a new job with economic uncertainty is a risk. Quiet quitting becomes an easy way out. Treat the job like it treats you, instead of being unemployed and looking for a job. This seems like something you can just turn on or off. But unfortunately it’s a state of mind. Once you think this way, it would be hard to get back to a positive workspace attitude. If you don’t get that, then good places won’t want to hire you. Can you keep “quiet quitting” for the rest of your life? I personally can’t. That’s obviously a privileged stance of an individual who can spend years “unemployed” with only a minor impact on my lifestyle. I understand that not everyone can afford that privilege, and I’m thankful for it. But if you find yourself in this situation, I urge you to remain out of your comfort zone and seek alternative employment ASAP. If you’re a manager who has the sense that employees do that, I suggest throwing them a lifeline. While you can’t change corporate policy, you can use the one-on-ones (which hopefully you have) to communicate with the employee. Have an actual conversation and try to help. Don’t talk about work. Talk about helping that employee, financially, emotionally, and be genuine. Don’t do it with the goal of getting an employee to perform. Don’t expect loyalty — give it. Repeatedly. It will come back to you. This will positively impact your future employment opportunities along the way.
Gene Kim
Author, Researcher, Speaker, Director, DevOps Enthusiast,
IT Revolution
David Brown
Founder and CEO,
TORO Cloud
Otavio Santana
Software Engineer and Architect and Open Source Committer
Tanaka Mutakwa
VP of Engineering,
Names and Faces
