Blow Up Your Meetings - Keep Your Do-It Crowd Focused on Delivering

Most programmers I know dread meetings. Meetings are the bane of their existence. They interrupt their creative juices – for what they perceive as no value. You can easily extend this to other knowledge workers that are part of ‘do it’ team that are involved in the design, build, test and implementation of apps into your organization – either for internal or external use. I’m talking about the group that spends their entire day in the ‘do it’ mode. This is not the occasional floater that briefly touches the effort and is then gone. 

I’ll go a step further and state that most people inside of organizations hate meetings – they’re usually run poorly and don’t provide meaningful outcomes. Then, creating the need for additional meetings.

I’ve made the transition to management and my day is filled with meetings – that’s my role and I’m used to it. There are days where I think about just spending my time coding, but, professionally, those days are now in my past. Some of these meetings are tactically driven to look at individual efforts underway and to remove roadblocks, others are more long term or strategic in nature. Those of us in Project Management or Management sometimes forget that we hired these folks to be the builders and that’s where they should be focusing their time. While we need to minimize time that these people spend in meetings, it is still a critical part of their job that hopefully gives them a richer understanding of what it is they are brewing up.

Let’s look at what makes the ‘do-it’ crowd productive:

• Being a part of a team – the culture!

• Understanding that what they do makes a difference.

• Long periods of uninterrupted time where they can focus on solutions.

• Ad-hoc collaboration to solve specific issues – note the word ‘ad-hoc’.

• Ability to learn – technology and the business.

• A manager that keeps the ‘bureaucracy’ away from them.

• Spending an hour or more in a room to get the current status.

• People in the process who are supposed to be decision makers who fail to make decisions.

• Meetings that rehash information that is already known or decisions already made.

• Leaders of meetings that do not have any focus – meetings with no Agenda, leaders that ignore the Agenda

• Leaders that don’t encourage everyone to give their opinion or to be heard

• Attendees that do not add value to the meeting and divert the discussion or are not engaged

Now, let’s think about the things that your ‘do-it’ crowd finds disturbing:
There are a lot of reasons to hate meetings. Unless run correctly, they burn thru real dollars by diverting your talented team members away from the very jobs you hired them to do in the first place. So what’s a Manager or Project Manager supposed to do?

First, blow up your meetings. Ask yourself if a meeting is necessary or if a short one on one conversation with the appropriate decision make would be more effective – you can share decisions with the team without taking them away from their work. Personal conversations provide significantly more value in solving a problem vs getting 20 people in room to try and reach a consensus. Who really owns the decision? Maybe you need to pre-meet with folks ahead of time to collect ‘intelligence’ to share with the decision maker. Provide them with the information you’ve collected and get a commitment from them to get a decision if they aren’t able to make a decision in your conversation.

If a meeting is truly necessary – think about the following:

1. Replace your status meetings with stand-up meetings. Include only the actual team members and limit the discussion points to what is being worked on and what assistance is needed to remove roadblocks. The Project Manager then has the responsibility to communicate the status outside of the team. The teams focus should be on sharing with each other and helping each other solve problems. No team member should need more than a couple of minutes and then your ‘do-it’ crowd can get right back to work. And, stand up, literally means stand up. Do it in where your developers are sitting, pull them to a corner of the room.
2. Blow up your meeting – I know I already said this, but blow up your meeting! First, be stingy on who is allowed to attend your meeting. Ask yourself what value each individual can bring to the meeting and what issues they can help solve. If they have no skin in the came and are not accountable or responsible for delivery of the decision, than boot them out. Next clearly define the purpose of the meeting, what decision points you are looking to lock in during the meeting. Share your agenda ahead of the meeting along with the background of what is going to be discussed – each item should have a summary that the attendee can review that identifies the issue, what has already been tried, what recommendations are on the table and the pros/cons of each recommendation. Once you know your decision/discussion points, time box each item and include the discussion time in each agenda item. When the meeting occurs, don’t rehash the discussion points and potential solutions, but use the time to get to a drive to a decision. As a leader of the discussion, make sure everyone in the room contributes to the discussion.
3. Bonus points – don’t meet unless you’ve pre-worked the meeting. Take a walk around the building and solicit input from the stakeholders in the meeting. If the folks you need to talk to aren’t in the same building – use video conferencing (preferred so that you can pick up the non-verbal signals) or use the phone. Please, please, do not do this via email or via text chats.

Your job as a Manager or a Project Manager is to enable people to delight your customers. If your organization is needlessly dragging people away from the jobs they were hired to do, you are failing them. You are impacting their ability to successfully achieve the results you hired them to deliver to the organization. You are failing your customers by delaying meaningful changes that allow them to use your products and services.

How are you helping your teams succeed?

If you'd like more information on my background: LinkedIn Profile

Your First Job ... Software Development!

So you got that job you wanted! You’ve been invited to join a team developing software … this is the moment you’ve been waiting for, it’s time to make a difference. So what’s your first move?

When you’ve landed that first job as a software developer, it’s important to create the foundation that will enable you to build long term value to the organization and team that you just joined. And, ultimately, to add value to the customers that will use your code – both internal and external. Yes, you were hired to come in and ‘create’, but that is not the only role you are expected to play and it is important that you develop the underlying skills and habits that build value within the team. Ultimately, setting up the conditions that will allow you to excel and become an important member of the overall team.

Below, are some things that you, as a developer, should think about and create action plans to help you settle in and create that foundation for longer term success:

1. Continue Your Education: You need to realize that your education never stops. You may have finished a phase of your education – high school, community college or a four year degree – but that is literally just the starting point. There is no way that the languages that you have learned to this point will be the languages in use by the time you end your career. If all else fails, you will be introduced to new frameworks, development paradigms and development tools. If you are to build value as a developer, you need to identify how you will continue to learn and how you will be seen as a positive agent of change. Don’t wait for the team that just hired you to invest in your skillset and overall professional knowledge. You will need to find ways to keep abreast of the changing technology, development paradigms, tools and frameworks. This will make you more valuable to the team and open up possibilities to play other, more expansive roles in your future. Some of this, you can do on the job, but if you really want to excel as a team member, you’ll find time outside your normal workday to continue to expand your knowledge.
2. Establishing a Mentor Relationship: If your boss has not assigned you a mentor, ask for mentor. This is important for multiple reasons. First, you want access to a resource that help you become familiar with the teams choices for tools, frameworks and other technology. Additionally, this person should help you navigate the expectations, rules and norms of the team. Last but not least, the mentor will also be available to assist you in how the company operates – what happens outside of the team that you need to be aware of and how to interact with other parts of the organization, learning the soft skills that will help you navigate your career.
3. Understanding the Technology Stack/Tools: Back to learning! Yes, one of your first tasks as a team member is to learn the stack that your team uses to build apps, the frameworks that they have in place to accelerate the development process and the tools that they use to plan, build, test and implement the code you build. This covers everything from the editor to understanding the layout of the development environment, what authorities you need to establish to access the environments and to build your apps and your test and build tools. And, yes, as a developer, you’ll be expected to do more than just write code. Use your mentor and team members to understand the overall stack used to build apps by the team, the apps that are typically supported by the team, the integration points between the apps you’ll be working on and other applications and interfaces that the organization supports.
4. Ask For Help: You are going to be overwhelmed! You need to stop telling yourself you’ve got this and ask questions to quickly close the knowledge gap between yourself and your teammates. Everything from what the accepted behavior is within the team – do people want unscheduled interruptions, do they prefer you schedule time with them to discuss roadblocks, how do you use the communication tools and what’s the norm – IM vs Slack vs MS Team vs eMails vs FaceToFace vs Video Conferencing, what are the standards the team follows MVC vs MVVM, syntax formatting standards, variable/object naming conventions. Right now, you are not the smartest cat in the room. Even if you scored perfect ACTs and had a 4.0 thru your collegiate career, your teammates have real world experience developing code and using the tools/frameworks and internal corporate processes that you simply have no experience with. Be humble and recognize what you can learn from others.
5. Be Humble: Your excited, you want to contribute, you want to show your teammates that you add value. Do yourself a favor – listen, listen some more and when you feel you’re ready to speak, listen some more. Your job is to learn from the folks who’ve already cut their teeth and know the ins and outs of the applications your working on as well as the expectations of the customers and the organization. Coming in with little or no practical experience and beginning to act as if you have the solution to every problem the team is having is a fast way to alienate the very people that you need to be successful. Listen to what they have to say, ask questions, understand why they want to do things certain ways and what the history is behind decisions. After you’ve spent plenty of time understanding, then contribute your solutions being mindful of the history of how the team got to where they’re at today.

And here are the more technical issues you’ll need to think thru to establish yourself as a net contributor within the team and to make that foundation your building a rock:

1. Security Is A Requirement: The days of being able to push out applications, api’s and frameworks without security consideration are over. Security needs to be a central consideration in the changes you are making, how you test those changes, how you implement those changes and how you support the changes in your production environment. The days where a ‘hole’ could be tolerated because nobody would really attack your organization are long gone. Highly skilled teams are actively scanning the internet and are using social engineering techniques in an attempt to infiltrate your organization and either hold it ransom or to steal the data so that they can use it to make money. Developers need to be aware of the role they plan in creating hardened applications and production environments that allow your customers to do business with you, but that put barriers in place that make it difficult for bad actors to wiggle their way past the front door. This not only includes changes in how you develop code, but ensuring you act as a good citizen by not opening emails or clicking on web site links that could be used to deliver ‘unwanted trojans’ into your environment.
2. Your Code is Bigger Than You: These days it is rare that an application can be written that is completely stand-alone. Most applications created today are expected to interact with other internal and external applications, data repositories used for ‘big data’ analysis or artificial intelligence models. You may be tasked with working on a single function, but  you need to be inquisitive and understand how your piece works with the greater whole – within the overall application being touched – or thru feeds to other systems, api’s that utilize the data you capture and any other way that your app/data could be used. Start learning the complete data flow of the application and the data used/touched by the application.
3. Code Reuse Is Encouraged: How things have changed! When I first started programming – yes I used a chisel and a stone – the internet did not exist. In other words, if you were creating something new, you were by and large pounding out all of that code. Sometimes you got lucky and you could reuse chunks of code that other developers had, but that was uncommon as code wasn’t really modular and you had to use sneaker net. Today, developers can hit GitHub, StackOverflow and other web sites to search for snippets of code, frameworks or libraries and to get answers to questions that they have on how to code something up. I remember the first time I was able to ask a question via the internet and someone in Australia answered my question. I was stunned – today we all take that for granted. Additionally, most organizations now have API’s that are used internally and documented in a way that makes it easy for developers to utilize. Why spend hours attempting to write something when you can call an API or obtain some free code via the internet (just pay attention to copyright).
4. Code For Tomorrow: This really highlights multiple things that you need to be aware of. One, what we write today, makes no sense tomorrow. I can’t even begin to tell you the number of times that I’ve written code, gone back in a year later and asked myself WTF! Seriously, sometimes what looks like an elegant solution today, looks like gnarly old junk later. So, a couple of things to remember. One, you need to create your code in a way that can be easily understood and is extensible. You don’t know today what business rules will change tomorrow that will cause you to have to go in and modify or extend the functionality that you’re creating. If you’re not familiar with the term micro services, you may want to educate yourself (see that whole learning thing again) so that you can create small snippets of code that can tie together to perform business functions. These can be reused and tied together in ways not seen today that will solve tomorrows problems. Additionally, take the time to comment your code. Each team is different as to the standards they have for when to create comments, but don’t think you are above having to comment your code. Someone else is most likely going to have to touch that code in the future – maybe you – and they are going to have no idea why you were making some of the coding decisions you have made to create your code. Be nice to your future self or that developer sitting next to you.
5. Code Reviews Are Mandatory: These are no longer optional. Unless you are a team of one – and even then, I would encourage you to find someone to act as your code reviewer. Today’s environments are complex and you have many more things to worry about that could go wrong. Security being a critical component. This isn’t just about ensuring that your coding style conforms to the standards of the team, this is about ensuring that your code is optimized to run in your production environment, that it is hardened and can’t be used as the back door into your systems, and can be used to mentor each other on coding techniques. I have seen newbs provide important feedback to veteran developers thru code reviews and this is a great opportunity for your more experienced developers to share their wisdom with the developers that will grow within your organization.
6. Unit Tests Are Mandatory: If you’re not testing your code, go back to square one and do not collect $200. Seriously, it’s 2019, if you don’t understand how critical unit tests and integration tests are to the success of your code, then get with the program. It is going to be tough for you to add value to the team you’re on if you’re are constantly breaking things – no better way to break bonds with your team. My teams will tell you that I’m very passionate on this point, probably only 2nd to team members understanding the data flow. Whenever I speak with high school or college students, I always tell them that if you don’t understand how to test your code, than you shouldn’t start writing the code. By the way, testing code doesn’t mean just testing the ‘success paths’, it means digging in and actually trying to break the code by using unexpected values or disconnecting things that your code believes should be there to successfully process whatever it is your creating. What happens if the call to the API fails because someone actually removed the location where the API is located or wiped out the service? What happens if you pass a numeric in where a string is wanted? What happens when the user fills out your forms with junk? What happens if they trying to inject SQL thru your forms? What happens if a bad actor attempts to use your API to sneak their way into the organizations systems? Plan for the worst and test to ensure it can’t happen – or at least reduce your risk exposure.
7. Your Estimation Skills Suck: Sorry, but almost every new developer sucks at making estimates. You’re too aggressive, thinking you can do more in a limited amount of time than you actually can. You’re not thinking thru what it takes to actually design, build, test and deploy your code. That’s not a bad thing, you just don’t have the experience yet. Before you tell someone that you can have that code done in a week – check in with your mentor and get their feedback. Trust me, you don’t want to be giving out dates that are unreasonable. One there will be an expectation that you meet those dates, and two, you’ll get a reputation for not being able to deliver. Learn from your peers and let them help guide you – it’s ok to say, ‘Hey, I need to review this with my boss or my mentor. Give me till the end of the day and I’ll let you know when I can have this done for you.’.

Here are some additional thoughts on specific items mentioned above that dive deeper into understanding the data used by the system, the flow of data thru the system and code reviews:

- Back to Basics - Data
- Follow the Data - Software Design, Development and Testing
- Code Reviews - A Must for any Team!

Developing code is more than just walking into the office, plopping down into your chair and pounding the keyboard. You’re now an integral part of the success of your team, your department, your organization and your customer. Take the responsibility seriously, and remember that you’re in the role you’re in to add value. Set yourself up for success by understanding your role and doing the things that will make the team realize that you want to be a part of the success, not to steal time away and make their jobs harder.

If you'd like more information on my background: LinkedIn Profile