DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Team Management

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.

icon
Latest Refcards and Trend Reports
Trend Report
DevOps
DevOps
Refcard #093
Lean Software Development
Lean Software Development
Refcard #008
Design Patterns
Design Patterns

DZone's Featured Team Management Resources

Leaders Make Their Own Problems

Leaders Make Their Own Problems

By Jade Rubick CORE
At some point, you begin to lead. This is very different than managing. The difference can be summed up with the phrase, “Leaders make their own problems." I’ll explain that in a bit, but first, let me tell you a story. When I First Realized I Was Missing Something When I first became a director, I had a conversation with another director named Jim. Jim: “So, you’ve been in this role for a month now. Have you figured out your vision for your organization?” Me: [What is he talking about?] I realized I was used to taking direction from others, and I had become a sort of “execution-” focused manager. I didn’t have any idea what my organization needed. I had no idea what the future should look like. I was managing my organization, not leading it. Interrogate Yourself I brought this up with an executive coach I was working with at the time. He encouraged me to set time aside every week to really think deeply about my area of the product. At first, it was hard to preserve the time I set aside. In my busy schedule, it seemed luxurious to save a couple of hours just for thinking, but it quickly became some of the most valuable time I spent each week. I would spend time each week thinking amount my organization, the product, and how things were going. I researched other products that competed with mine. I spent time using the product. I thought critically about our technical and product failings. I ended up developing a better sense of what possible futures I could create. I started to see possibilities that were invisible to me. I started to learn how to lead. Mental Models: Try and Catch Them All! At around this time, my manager challenged me to start using more mental models in how I assessed my organization. He suggested looking at the situation from the point of view of: A systems thinker (this was my default) An architect A product manager A designer Most leaders use their own experience as their main mental model. Being able to add new mental models to your toolkit makes you more flexible. Each mental model can alter what you think the future should look like, and what the present should look like. It can also inform you of the actions you should take to make things happen. As I started developing a habit of looking at things from other mental models, I began to see blind spots in my previous ways of looking at the world. Interrogate Yourself With What Exactly? Each week, I sat down and looked at an evolving set of questions. I would go through the list and write answers to the questions on the list. Here is my list of questions: Review High-Level Objectives What are the results that are needed? What needs to be true in a year? X needs to be Y by Z. What would need to change for that to happen? What are the implications of that need? How are the teams performing? On time, hitting the mark, right characteristics? How are they performing AS a team? Where are things on the path to fail? What’s the worst thing that could happen? Is there anything I think my boss is making a mistake on? Can all of my reports take over my job in 1-2 years? What seems like it’s not working right now? What’s going well that could be turned into a repeatable process? What should I worry about? What do my managers need? What does my org need? What do I need? Review Progress Against Objectives How on track is everything? How long should the rope be for all of my objectives? Agree to them with other people. For example: when should we expect reliability to improve? Review team health. Review progress against goals. How are team members doing against their goals? Identify Next Actions What actions should be taken? I found writing down the answers to these questions to be tremendously helpful. If you’re an external processor, you might find it more useful to talk with others about these questions. For me, I did a bit of both. I found a few other people that I would talk about these things with. But I found the private thinking time valuable — it gave me more material to test with others in conversation. Leaders Make Their Own Problems A leader is a person that asserts a future for a group of people. If you want to lead, you have to learn to make your own problems. And hopefully, you’ll find some of the processes I’ve used to develop that future useful. Do you have your own methods? Please share them with me! Thank You Jim Ruppert helped me see that I didn’t have a vision for my organization. Robert Goldmann helped me learn the perspective I needed to lead better. He helped me develop some of the questions on this list. Alex Kroman challenged me to consider things through multiple mental models. More
Building Security Champions

Building Security Champions

By Tanya Janca
Most of us that work in cyber security are well aware that there are not enough people to fill all of the positions that we have opened. There is a severe shortage of trained and experienced people who are capable of securing the systems that we are entrusted to protect. Application security engineers, DevSecOps professionals, security architects, you name it, there's a shortage. We will never have the staff, budget or time to do all the security work we want to do. One of the ways that we can address this is by scaling our security teams and programs. When I say scaling, I don't mean what you do to a fish after you catch it. I mean finding a way to do more with less. This can involve automation, creating self-service systems, and many other potential solutions. In this series of blogs, we will discuss how you can solve this problem by building a security champions program for your organization. What Is a Security Champion? A Security Champion is a team member that takes on the responsibility of acting as the primary advocate for security within the team and acting as the first line of defense for security issues within the team. Or, more plainly: The person who is most excited about security on a team. They want to read the book, fix the bug, or ask security questions. Every time. Security champions are your communicators. They deliver security messages to each dev team, teaching, sharing, and helping. They are your point of contact, delivering messages to and from the security team and keeping you up to date on what matters to your team. They are your advocate. They perform security work, for their dev team, with your help. They also advocate for security, asking questions in situations you would have been left out of. Raising concerns you might have missed. They are a peer for everyone on their team and can influence in ways that you yourself cannot. In the next few paragraphs, we will cover how to build an amazing security champions program! We will follow this recipe: Recruit Engage Teach Recognize Reward (Over)Communication Metrics and Data Conclusion (Don't Stop!) How Does One 'Attract' Champions? The #1 most important rule of recruiting security champions is that you must attract them. Do not "volun-tell" someone to be a security champion. That person is not going to do their best for you, and they or certainly won't enjoy the experience. Attract the right people instead of forcing them. Performing Outreach Use lunch and learns to teach about security. Arrange security training. Anyone who asks questions or attends all the events is a potential champion. Use interesting titles for events if you can. Add a note to your email signature saying you are looking for champions. Put a sign on the fridge in the kitchen. Talk about it at the all-staff meeting. Send an email to all of IT. Security Champions at Work! Use lunch and learns to teach about security. Arrange security training. Anyone who asks questions or attends all the events is a potential champion. Use interesting titles for events if you can. Add a note to your email signature saying you are looking for champions. Put a sign on the fridge in the kitchen. Talk about it at the all-staff meeting. Send an email to all of IT. Observe Pay attention to who responds, attends events, asks questions, and who is 'always there.' Those are the people you need. Adjust Your Attitude Change your team's mantra to "I am here to serve you," and your team will attract even more candidates. Saying "you are my customers" to the rest of IT if you are a security professional, is basically the truth. Plus, you always get more bees with honey. #2 most important rule of recruiting: ensure their manager is on board. You don’t want this person to have to fight to do work for you or feel conflicted. Ensuring their manager is comfortable. Engaging Your Champions If we want IT professionals to join our security champions programs, we must make participating interesting and appealing. We want to motivate them; to do extra work on top of their regular job, to care about security, to learn a lot of new things, and to work with us. So it needs to be good. Engage: To occupy, attract, involve – in security activities! To participate or become involved – with your champs! A Few Ideas For Making Your Champions Feel Engaged If possible, bring them on a security incident related to software. Teach them what it's like to respond, the consequences, and just how much damage insecure code can cause. Share (appropriate) secrets with your champions. If you are going to share quite sensitive info, inform them of the concept of 'need to know, then 'Deputize' them onto your team for that one meeting. Being vulnerable and admitting mistakes is a great way to get buy-in and interest. Let your champions see everything first. New tools, documents, policies, changes, etc. And ask their opinions. First, they will likely have great ideas, and second, it makes them feel like they matter. Create a mailing list for your champions to tell them about new security stuff. Send them links to podcasts, articles, events, or anything else that you think is relevant and that they may find interesting. Meet with them 1:1 once every month, and have a pre-set list of questions. Potential questions (thanks to my friend Ray at Hella Secure Blog): What are you working on? What are you going to be working on next? Do you need any help? These questions will spark conversation and lead you down the right path. That said, when you ask questions like this, brace yourself for potentially bad news so that you can play it cool if they reveal something that makes you cringe. Hold team-building events, and let them know each other. Having a friend on a team always makes it worth coming back. Invite them to join security communities, such as OWASP, or We Hack Purple Community (of which they are free to be part of!). There are many ways you can make the champions feel engaged, and one of the best ones is to give them training, which is what we will talk about next. Teaching Security Champions You are in a room full of brand-new security champions, and they are itching to learn all about 'cyber'; what do you do? What do you teach them? How do you impress them? Only teach them what they need to know. Nothing more. As someone who creates security training professionally, I have to say I've seen a LOT of filler. Extra content that just does not need to be there. Software developers do not need to know the history of Diffie-Hellman or the difference between symmetric and asymmetric encryption unless they are building encryption software. So don't try to teach it to them unless they have a keen interest and have asked about it. What they really DO need to know is: What you need, expect and want from them, as champions. You should define the goals of your program and share them with your champions. Share your plans for them as much as you can. Give them timelines, training information, or anything else you have. You need to clarify what you expect, or you may not get it. Technical Topics For Teaching Your Security Champions: Formal training on secure coding with labs! Threat modeling Secure architecture (whiteboarding) Code Review How to fix the bugs they find. Repeat yearly as a minimum. Topics Specific to Your Organization: Which policies, standards, and guidelines apply to them? Help them create missing guidelines. Teach them how to be compliant, and help them get there. Their role during an incident. Job shadowing Hold consultations to let them provide input on the policies affecting them. Trust me; their feedback will be priceless and make them feel heard. The last topic you need to ensure they learn is tooling. If you expect them to use a tool, you need to show them how, what the output means, how to validate the results, and how to install and configure it. It is also your job to either help them pick excellent tools or involve them when you are choosing tools for them. Recognizing and Rewarding Security Champions Suppose you've ever read the book The 5 Love Languages or articles summarizing the five love languages. In that case, you are aware that there are predictable patterns in how people respond to various acts of kindness. Someone's "love language" is the specific type of kindness that they are most affected by. For example, someone whose love language is "words of affirmation" would respond very well to receiving a glowing performance review, a compliment on a new article of clothing, or accolades from their colleagues about a project they worked on. You may be wondering at this point if you accidentally clicked on an article from a women's fashion magazine, not a technical article from Tanya Janca, AppSec Nerd Extraordinaire. Please have a bit of faith, and read on. The Five Love Languages Are: Gifts Words of Affirmation Physical Affection Spending Quality Time Acts of Service When we are creating a security champions program, it's very important that we ensure the champions feel appreciated. We don't want them to feel squished into doing two jobs for only one paycheck. One of the biggest challenges that security teams face when creating a champions program is having it fall apart after the first few months, either due to the security team losing steam or champions losing interest. We need them to feel very aware of our gratitude and interest in the program itself for them to continue to want to serve the security team's agenda. As you likely already figured out, not all the love languages listed above are work appropriate. We can't run around giving hugs or holding hands with other employees. That said, we can adapt most of them for work situations so that we can show the champions they matter to us in appropriate ways that support our security program. Below is a non-exhaustive list of several ideas to make your champions feel as valuable as you know they are for your program. 1. (Security Related) Gifts Physical or digital security-related gifts; books, videos, training, and CTFs. Create a Certificate to put on their wall. Stickers, posters, or any other decoration that is security-focused. Tickets to a conference or training. 2. Words of Affirmation Make sure to put a note in their performance review about them being a champion. Tell their boss every time they do something that makes a big difference. Send them an email and tell them when they did something big, let them know that YOU saw. Recognize them in front of their peers (special virtual background, a star on their name is slack, etc.) Digital badges for signature blocks. 3. Physical Affection High Fives are the only recommended form of physical affection that you should show another employee. High fives signal success and your approval of whatever they just did. (And only give high fives if you are confident that the employee is comfortable. If they seem hesitant, don't do it. Please also be mindful that some religions and cultures do not allow those of the opposite sex to touch each other; please be respectful if this applies. Never push physical touching at work.) 4. Spending Quality Time Giving them your time is a reward. When you do, give them your undivided attention (put your phone away), and turn your body towards them. Let them see a new tool first, and give them a "sneak preview" ahead of everyone else. Let them help you make decisions. Ask for advice from them and feedback, then take it seriously. Invite them to attend security events with you. Whenever you meet with them, this is quality time. Ask them: What are you working on? What are you going to work on next? Do you need any help? 5. Acts of Service Help them with more than just security. Are you good at design? Help them with it! Are you great at presentations? Offer to let them practice in front of you. You don't need to do this very often; just once can make a huge impression. Make introductions where appropriate. "Oh yeah, Chris from QA uses that tool; I'll introduce you so you can learn." Find answers they need to security questions and problems. Never leave them hanging. When people feel appreciated and valued at work, they work harder (many studies show this to be true). Your champions already have full-time jobs on other teams; they are going above and beyond for you. Let them know that you are very aware of them by always making them aware of it with your actions, not just your words. (Over)Communication With Your Security Champions To start off with, pace yourself. Often when I speak to security teams who have a failed program, they tell me how they started off very strong. "We gave them two different pieces of training, two workshops, and three lunch and learned, all in the first three months. Then we were exhausted. We haven't done anything with them in over a year." Unfortunately, this scenario is far too common. To pace yourself, I suggest meeting each champion monthly for 30 minutes. Then hold one lunch and learn and send one email to the champions. This might not sound like much, but you must remember they are already doing a full-time job for your organization. In my 1:1 meetings, I like to ask the following questions (adapted from Ray Leblanc's Security Champions article on Hella Secure blog): What are you working on? What are you going to work on next? Do you need any help? Each of these questions is open-ended, with the hope that it will prompt a meaningful conversation. I usually take notes during the meeting and then send them to both of us, with any action items for either of us highlighted in bold. (Note: I've used this technique to get many of my previous bosses to do things for me. Set a reminder for a week from then, and then reply-all to that email chain and ask: "Any updates on these action items?" It works like a charm!) In your lunch and learn (which does not need to be at lunchtime or involve food), teach them something you want them to know. Do not teach them things they do not need to know unless they asked for that topic specifically. During this session, you or a teammate can teach, or you can show them a training video you like or even a recording of a conference talk that really hit home for you. If you show them something pre-recorded, ensure you watched it first, you don't want to waste anyone's time with death-by-powerpoint. The more fun you can make these sessions, the better. If you're up for it, invite all of the developers and let everyone learn something new! Ideas For Lunch and Learn Topics The specifics on how to apply policies, standards, and guidelines. This could be a secure coding workshop or a threat modeling session. Talks about the top vulnerabilities that you are seeing in your own products, including the risks they pose to your specific business model. Workshops on how to use the tools that your team wants them to be responsible for. Especially how to configure them, how to validate results, and where to find information on how to fix what they find. If they are responsible for design or architecture, give them secure design training. Tell them about a security incident your team had and how it could have been prevented (assuming you are allowed to share this information). Hold a consultation on the new policy, standard, or guideline your team is considering publishing. Ask for their feedback, then adjust your documents accordingly. Remember to take attendance (for metrics) and take notes of any questions for you to follow up on. The Monthly Email Sometimes you just don't have time to do a lunch and learn event or hold 1:1s, but you still need to send a monthly email. The monthly email lets the security champions know what's going on and that they still matter to you. The program is still running because you sent an email. If you don't send this email and you haven't touched base in any other way, this leaves a space where your program may start to disappear. The monthly email does not need to be fancy and doesn't need to say a lot. Generally, the monthly email says: What events are happening this month at your org (lunch and learn, all staff, any other meeting they should know about) Any updates your team has (new policy, the new tool, project updates, etc.) Anything interesting from the news that they may find valuable Any local security events they may be interested in Any podcasts, videos, blog posts, or any other media that is relevant, and you feel relates to them, about security (of course) I live in Canada, and in Canada, we are a country of immigrants. This means we have many, many different religions represented in most workplaces. In December, there's Hannukah, Ramadan, Christmas, and more, and often people take time off for these special holidays. This means having a large meeting in December is darn near impossible. This is the type of situation where you just send the monthly email! It could say something like the following: Hello Security Champions! As it is December and many of you will be off celebrating various holidays, we are not going to have any events this month. We also want to wish you happy holidays, and we hope you enjoy all the snow we got this past weekend! In January we are going to boot the Champions program back up with a lunch and learn on XSS. As some of you are aware, we’ve found it in about 1/3 of our custom apps, and we want to stomp it out in the new year (with your help of course!) An invitation will arrive later this week. In the meantime, please check out this XSS Deep Dive by Tanya Janca. We’re going to cover this topic a bit differently than she does, but it gives you a good idea of what we are up against. Have a great December folks! Sincerely, The Security Team My hope for this section of the article is that you remember to continue communicating with your champions. Don't let your program slip; it will disappear faster than you think. When in doubt, send them an email and check-in. Metrics and Data Following my conference talks, you likely saw my Security Metrics That Matter presentation and understand that I love data. You may wonder why metrics are important. The answer is twofold. We can use data and metrics to report to our bosses and show them we are succeeding. It's evidence of what we are doing and how well it works. You can then use that data again to ask for more resources (staff, tools, budget), a raise, or other changes. The second reason is so that we, ourselves, can improve. We want to improve our program, ourselves, and our results. We can see which activities or methods produce better results when we measure our activities and their impacts. We can then use that information to change our approach for the better. It is important, however, that we do not become fooled by vanity metrics. Vanity metrics are numbers that make us look good but don't necessarily mean anything. My talk on this subject has several stories, but let's tell one. I used to work somewhere, and we all wrote blog posts. We were measured on how many “clicks” we got. A colleague of mine got 10X the number of clicks that I did, and I asked him how he did it. He explained he got the most clicks on Reddit. I was unfamiliar with the platform but thought I would give it a try. First though, I asked for extra data: I wanted to know how long people were staying on our articles. It turned out that people were staying on my articles approximately 1.5 minutes (which means they were reading the whole thing), and on his they were staying an average of 1.5 seconds (which means almost no one was reading the article, they were just clicking the link. This is commonly known as a “bounce”.) The purpose of our jobs was to write articles to help customers know how to use our products, and this means a bounce wasn’t valuable. Armed with this new information, we started comparing different platforms, and it turned out almost all traffic from Reddit were ‘bounces’. I also noticed that my Twitter followers were significantly more likely to read the article when compared to LinkedIn, and LinkedIn got better results than Reddit. My colleague started focussing on sharing links on Twitter (he had more followers than I did), and I started trying to get more followers on the same platform. It turns out that measuring clicks was a vanity metric. The rest, as they say, is history. Now for your security champion program metrics! Measure the following things to see what's working and what's not. Don't forget to report upwards about the ROI (return on investment) your champions program has produced! How many new security champions have you attracted? Measuring program engagement: how many people attended an event, how many people reported issues to you, how many people asked questions. Use the bug tracker for metrics on how many security bugs are being reported and fixed, especially if you have targeted a specific bug class. Also, count how many new instances of that type of bug appear; hopefully, this number will be very low. Instances where champions have told you about a security issue you would not have known about otherwise. If the champions report better work satisfaction and/or fewer missed days of work. Gather stories of your champs saving the day, providing help to their teammates, or anything else that makes for a good story-telling session for upper management. Conclusion: Security Champions Here Are a Few More Tips to Conclude This Long Article: First, start by defining the focus of your program and what is expected from champions. Be realistic; you can only expect one to four hours of maximum effort from them per week. If someone takes a security course but is not on the security team, they may make a good champion. Reach out and introduce yourself. If the mantra of the security team is "it's my job to help you do your job securely," "you're my customer," or "I'm here to serve you," that is very attractive; however, if your team is known as 'the ministry of NO!', you will have difficulty attracting volunteers until you turn over a new leaf. Record every group session and save them. Then, create an onboarding set of champion videos from these recordings so that you can auto-onboard new champions. Some of the videos can also be used to onboard new software developers or other IT staff. Save all the videos so anyone who missed them can see them later. Then, offer up the list of videos to everyone at your organization, if appropriate. Include a TTT (train the trainer) package so your security champions can train their teams as needed. For instance, if you want your champions to give training or talk to their teams, have them follow your package. The package should contain 1) your slides, 2) demo information and instructions to set it up, 3) a video of you giving the talk/training, and 4) a video of you explaining what you are trying to get across for each slide and the entire demo, speaking as though you are teaching someone to give the talk on your behalf. For an example of this, see mine! PS... Feel free to give these talks yourself at your workplace. Lastly, don't stop. Don't give up. Perseverance is the thing that will make this program work. As your program continues, it will grow, and the value that you receive from it will also grow, scaling upwards over time. You and your organization can do this; all it takes is dedication and time. Please feel free to with questions, or even better, tell me about your success with your security champions program! More
Classifying Severity Levels for Your Organization
Classifying Severity Levels for Your Organization
By Vishal Padghan
Leading Engineers in Uncertain Times: A Conversation with CircleCI, Blockchain.com, and Oliver Wyman
Leading Engineers in Uncertain Times: A Conversation with CircleCI, Blockchain.com, and Oliver Wyman
By Conor Bronsdon
How to Make On-Call Work for Everyone
How to Make On-Call Work for Everyone
By Shaked Askayo
Engineering Productivity: What Not to Do
Engineering Productivity: What Not to Do

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.

By Ralf Huuck
Creating Self-Serve DevOps Without Creating More Toil
Creating Self-Serve DevOps Without Creating More Toil

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.

By Shaked Askayo
Daily Standup Meeting: Ways To Keep It Short and Effective
Daily Standup Meeting: Ways To Keep It Short and Effective

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.

By Dharin Parekh
All You Wanted To Know About Custom Fields in Project Management
All You Wanted To Know About Custom Fields in Project Management

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.

By Sandeep Kashyap
Code Churn: An Analysis of Troublesome Workflows and Possible Countermeasures
Code Churn: An Analysis of Troublesome Workflows and Possible Countermeasures

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.

By Hamza Ghufran
10 Project Manager Objectives to Improve Performance
10 Project Manager Objectives to Improve Performance

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!

By Fred Wilson
Engineering Manager: Continuous Feedback
Engineering Manager: Continuous Feedback

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.

By Miguel Garcia
The Art of Engineering Management
The Art of Engineering Management

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.

By Alireza Chegini CORE
Learn the Weekly Rituals You Should Master as a Software Project Manager
Learn the Weekly Rituals You Should Master as a Software Project Manager

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.

By Jade Rubick CORE
Quiet Quitting Is About Loyalty
Quiet Quitting Is About Loyalty

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.

By Shai Almog CORE

Top Team Management Experts

expert thumbnail

Gene Kim

Author, Researcher, Speaker, Director, DevOps Enthusiast,
IT Revolution

Gene Kim is a multi-award winning CTO, researcher and author. He is the founder of Tripwire and served as CTO for 13 years. He has written three books: “The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win,” “The Visible Ops Handbook” and “The DevOps Handbook.” Gene is a huge fan of IT operations, and how it can enable developers to maximize throughput of features from “code complete” to “in production” without causing chaos and disruption to the IT environment. He has worked with some of the top Internet companies on improving deployment flow and increasing the rigor around IT operational processes. In 2007, “ComputerWorld” added Gene to the “40 Innovative IT People to Watch, Under the Age of 40” list, and he was named a Computer Science Outstanding Alumnus by Purdue University for achievement and leadership in the profession. @RealGeneKim ‏
expert thumbnail

David Brown

Founder and CEO,
TORO Cloud

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎
expert thumbnail

Otavio Santana

Software Engineer and Architect and Open Source Committer

Empowering staff-plus engineers to deliver highly scalable software on the cloud, so they can become influential in their companies and in the market, and move their technical careers to the next level.
expert thumbnail

Tanaka Mutakwa

VP of Engineering,
Names and Faces

I'm a technology leader who is driven to help software engineers have fulfilling careers.

The Latest Team Management Topics

article thumbnail
Best Practices for Writing Clean and Maintainable Code
In this article, readers will learn some best practices for writing clean and maintainable code in software development and best practices for error handling.
January 24, 2023
by Ranveer Jain
· 1,795 Views · 1 Like
article thumbnail
Classifying Severity Levels for Your Organization
This blog helps you understand levels of severity and how they can enhance your incident response process.
January 16, 2023
by Vishal Padghan
· 1,947 Views · 1 Like
article thumbnail
A Data Warehouse Alone Won’t Cut It for Modern Analytics
The data warehouse market has evolved since the creation of OLAP; now we need to evolve as well in order to meet the needs of modern analytics.
January 6, 2023
by David Wang
· 2,996 Views · 1 Like
article thumbnail
10 Most Important Tools to Boost Your Productivity as a Developer
Developing a good workflow in a fast-paced environment with tight deadlines is crucial. It is, therefore, important to consider productivity as a metric.
January 5, 2023
by Karan Rawal
· 3,738 Views · 3 Likes
article thumbnail
Technical Debt Growth: How Can It Happen Without Realizing It?
The biggest fear programmers face when having to take care of an old project is the legacy code and the technical debt growth.
January 4, 2023
by Ileana Diaz
· 2,045 Views · 1 Like
article thumbnail
How to Make On-Call Work for Everyone
Looking for your next job? Building out your tech organization? How on-call is handled can make a huge impact on your success.
January 1, 2023
by Shaked Askayo
· 4,787 Views · 4 Likes
article thumbnail
Leading Engineers in Uncertain Times: A Conversation with CircleCI, Blockchain.com, and Oliver Wyman
In this recent panel from the Interact conference, three top engineering leaders discuss how times are evolving for development.
January 1, 2023
by Conor Bronsdon
· 3,987 Views · 2 Likes
article thumbnail
Building Security Champions
Security Champions help you scale your security programs. This article describes how to build up an amazing program in your organization!
December 26, 2022
by Tanya Janca
· 3,617 Views · 2 Likes
article thumbnail
Rescue Project: How to Help and Approach
Over two-thirds of organizations suffered at least one project failure the previous year. So today, let's focus on less severe cases, which can still be saved!
December 26, 2022
by Michał Matłoka
· 3,772 Views · 2 Likes
article thumbnail
Daily Standup Meeting: Ways To Keep It Short and Effective
When run effectively, daily standups can be a huge factor in making significant progress in projects and eliminating blockers quickly.
December 21, 2022
by Dharin Parekh
· 4,012 Views · 4 Likes
article thumbnail
Why DevSecOps Automation Is Important for Your Business
Let’s dig deep into the concept of DevSecOps automation and understand how you secure your application workflows.
December 15, 2022
by Gilbert Martin
· 2,769 Views · 1 Like
article thumbnail
Creating Self-Serve DevOps Without Creating More Toil
My team was mouthing off RTFM every time a dev would ask them a question. It needed to end.
December 15, 2022
by Shaked Askayo
· 3,533 Views · 4 Likes
article thumbnail
What Is a Project Baseline and Why Is It Important?
If you want to efficiently manage, oversee, and keep track of the changes in your business, a project baseline is what you need.
December 14, 2022
by Vartika Kashyap
· 3,337 Views · 1 Like
article thumbnail
Code Churn: An Analysis of Troublesome Workflows and Possible Countermeasures
Explore potential workflows that cause code churn and discover countermeasures that leaders can use to mitigate the impact of churn.
December 6, 2022
by Hamza Ghufran
· 2,471 Views · 1 Like
article thumbnail
All You Wanted To Know About Custom Fields in Project Management
Custom fields allow you to include essential details that are unique to your work process and gain better insight into your projects.
December 5, 2022
by Sandeep Kashyap
· 2,711 Views · 1 Like
article thumbnail
Agility and Scrum According to OpenAI’s ChatGPT
Will Scrum Masters, agile coaches, PMs, and POs be rendered obsolete?
December 4, 2022
by Stefan Wolpers CORE
· 3,683 Views · 2 Likes
article thumbnail
10 Project Manager Objectives to Improve Performance
Project manager outlines are essential to long-term performance and project longevity factors. Here's what experts suggest doing for optimal results.
December 1, 2022
by Fred Wilson
· 5,323 Views · 3 Likes
article thumbnail
What Is Agile Methodology In Software Development?
Agile software development is a group of approaches based on iterative development, where requirements and solutions are developed through teams. learn more.
November 30, 2022
by Mario Olomu
· 4,271 Views · 1 Like
article thumbnail
Process Debt Is Something You Should Care About
Process debt is the implied cost of having to perform additional work or actions caused by not having the right elements in place.
November 29, 2022
by Ramon Felip
· 6,991 Views · 4 Likes
article thumbnail
What Is Distributed Tracing?
Distributed tracing is an observability data source designed to trace a transaction across a distributed microservices environment that tells you exactly where a problem is happening. Learn more.
November 22, 2022
by April Yep
· 4,100 Views · 2 Likes
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • ...
  • Next

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: