Forem: Saheed Oladosu

An Introduction to Container and Containerization

Saheed Oladosu — Tue, 26 Jan 2021 18:53:28 +0000

Before I jump into what container means and how containerization improves modern-day application deployment. The default way to deploy an application was on its own physical computer. To set one up, you would find some;

• Physical space,
• Power,
• Cooling,
• Network connectivity,
• Install an operating system,
• Any software dependencies, and
• The application itself.
If you need more processing power, redundancy, security, or scalability, what would you do?

Well, you would have to add more computers. It was very common for each computer to have a single purpose. For example database, web server, or content delivery.

This practice, as you might imagine, wasted resources, and took a lot of time to deploy, maintain, and scale. It also was not very portable. Applications were built for a specific operating system and sometimes even for the specific hardware as well.

In comes the dawn of virtualization. Virtualization helped by making it possible to run many virtual servers and operating systems on the same physical computer. A hypervisor is the software layer that breaks the dependencies of an operating system with its underlying hardware and allows several virtual machines to share that same hardware. KVM is one well‑known hypervisor.

Today, you can use virtualization to deploy a new service quickly. Now adopting virtualization means that it takes us less time to deploy new solutions. We waste less of the resources on those physical computers that we are using. We get some improved portability because virtual machines can be imaged and then moved around.

However, the application, all its dependencies, and operating system are still bundled together. It is not very easy to move from a VM from one hypervisor product to another. Every time you start up a VM, its operating system still takes time to boot up.
Running multiple applications within a single VM also creates another tricky problem. Applications that share dependencies are not isolated from each other. The resource requirements from one application can starve out other applications of the resources that they need.

A dependency upgrade for one application might cause another to stop working. You can try to solve this problem with rigorous software engineering policies. For example, you could lock down the dependencies that no application can make changes to. But this leads to new problems because dependencies do need to be upgraded occasionally.

You can add integration tests to ensure that applications work. Integration tests are great, but dependency problems can cause new failure modes that are hard to troubleshoot. It really slows down development if you must rely on integration tests to just perform basic integrity checks of your application environment.

Now the VM‑centric way to solve this problem is to run a dedicated virtual machine for each application. Each application maintains its own dependencies, and the kernel is isolated. So, one application will not affect the performance of another. What you can get, as you can see here, are two complete copies of the kernel that are running. But here too we can run into issues as you are probably thinking. Scale this approach to hundreds of thousands of applications, and you can quickly see the limitation.

Just imagine trying to do a simple kernel update. So for large systems, dedicated VMs are redundant and wasteful. VMs are also relatively slow to start up because the entire operating system must boot.

A more efficient way to resolve the dependency problem is to implement abstraction at the level of the application and its dependencies. You don't have to virtualize the entire machine or even the entire operating system, but just the userspace. The user space is all the code that resides above the kernel and includes the applications and their dependencies. This is what it means to create containers. Containers are isolated user spaces for running application code.

Containers are lightweight because they don't carry a full operating system. They can be scheduled or packed tightly onto the underlying system, which is very efficient. They can be created and shut down very quickly because you're just starting and stopping the processes that make up the application. And not booting up an entire VM and initializing an operating system for each application. Developers appreciate this level of abstraction because they don't want to worry about the rest of this system.

Containerization is the next step in the evolution of managing code. You now understand containers as delivery vehicles for application code. They're lightweight, standalone, resource‑efficient, portable execution packages. You develop application code in the usual way, on desktops, laptops, and servers. The container allows you to execute your final code on VMs without worrying about software dependencies like;

• Application runtime,
• System tools,
• System libraries, and
• Other settings.

You package your code with all the dependencies it needs, and the engine that executes your container is responsible for making them available at runtime.

Containers appeal to developers because they're an application-centric way to deliver high‑performing and scalable applications. Containers also allow developers to safely make assumptions about the underlying hardware and software. With the Linux kernel underneath, you no longer have code that works on your laptop but doesn't work in production. The container is the same and runs the same anywhere. If you make incremental changes to a container based on a production image, you can deploy it very quickly with a single file copy. This speeds up your development process.

Finally, containers make it easier to build applications that use the microservices design pattern, which is loosely coupled, fine‑grained components. This modular design pattern allows the operating system to scale and also upgrade components of an application without affecting the application as a whole.

How to Build a Successful Team

Saheed Oladosu — Tue, 22 Sep 2020 11:46:55 +0000

In my posts on Top 4 Reasons behind Building a Team and Reasons Why Teams Fail. I discussed reasons why teams are put together and reasons why teams fail respectively. So, how do we build a Successful Team? Before we jump into tactics let’s talk about the definition of success.

These are the questions you can ask to get what success could mean to your team.

· How would you define a successful team? You might measure team success by the cohesiveness of the team.
· Was the team close?
· Are they a tight organization that from now on has one another’s backs?
· Would you measure success based on the culture of the team? Or is the success of the team boiled down to having successful deliverables?
· Was the leader a great leader and therefore made the team successful?
· Was it about the individual willingness?
· Was everybody ready to give it their all and do the best they could for the team?
· Did everybody walk away loving what they did? Or are they kind of resentful about even being on the team in the first place?

Perhaps you measure success by the amount of planning that went into the team projects or clarity of vision or purpose. Maybe you measure success by how well the communication was of the team. Maybe you’re just looking at the leadership of the team. You might measure team success based on the attitude of the team.

Typically, people look at the final deliverable of the team and that’s what determines whether the team was “successful” or not. As a business owner and a manager, there might be other reasons why you put people on this team. It might have a lot more to do with the culture and cohesiveness than a final product, especially if you have a product that’s not that important. You might have seen this in organizations where people were put on a project that didn’t seem to be that important.

The project and the team might have been a vehicle to help pull people together;

· To get a shared vision,
· To develop the culture,
· To build unity in the organization, etc.

Teams are together for more than just getting a final deliverable out. It seems to be a popular idea right now in corporate World that we need to embrace failure. We need to allow failure and not be afraid of failure.

The idea is that failure means that we’re getting closer to a more successful result. I would invite you to think about the teams you’re on or that you’ve ever been on and think about what the feeling of failure is or has been. Can you imagine an R&D department where failure wasn’t an option? Failure’s part of the package. They need to fail in order to get closer to their success.

Now let’s talk about the tactics on how to build a successful team. To build a successful team, you must have an understanding of the following;

A Shared Vision

Something that can help your team be more successful is to make sure that you have a shared vision.

· What is the source of the vision or the result of your team?
· Is the source coming from inside or is it coming from outside?

Let’s explore this a little bit. Imagine that the circle is your team. If your vision comes from within the team you have more buy-in. If people from within the team are creating and defining it they’ll be bought in more to their ideas. One of the problems with this is that the vision might be completely misaligned with the vision of your customers.

Let’s say that the vision comes from the outside. Your customers are now telling you what the vision and the purpose of the team is. One of the benefits is that perhaps your vision will be more aligned with what their vision is. However, if you’ve worked with multiple customers on the same project, you might know that different customers have different visions or ideas of what they want.

If your vision is coming from the outside I encourage you to interview any of the stakeholders or people who have an interest in the final deliverable or the product or project and make sure that you get a comprehensive view of what they all think.

Shared Goals

In addition to having a shared vision, even with the people outside of your team, let’s talk about sharing our goals. Before we do that let me just differentiate vision and goals. The vision is;

· What are we going to have accomplished when we’re done?
· What is a deliverable going to look like?
· What is our team going to look like regarding unity and culture, things that we discussed at the beginning of this course?

Different from that end result, the goals might be defined as things to do along the path to get to the vision, maybe tasks or deliverables. Everybody on the team should understand what the tasks or deliverables or the goals are for them individually, but it’s also very helpful if they understand what the goals are for other people on the team. What are the team level goals or the sub-team level goals or the individual level goals?

Sharing these goals could be just as important as sharing the vision. Somebody might look at the list of goals or tasks and say, you know what, that’s interesting, but it’s not aligned with our vision, it’s not something that will help us get to our vision.

Communication

When you think about communication, various people should get various types of information. You don’t want to leave team members in the dark sharing some things with certain parts of a team and other things with other parts of a team.

That might be appropriate based on the project or the sensitivity to security or the size of the team, but think about who’s on the team and what information they need to know. What you communicate to people in the team might be very different than what you communicate to the customers.

These are the people who are really excited about the final product that you’re going to put in front of them, but they might not need to know about everything that went into making the product or the discussions or maybe arguments that went on behind the scenes to get to the final product. They shouldn’t want to know about any of the drama that might have led up to getting a final product done.

The management outside of the team also needs to know certain things, but just like the customers, they don’t need to know everything that’s happening. They might need to know things that are happening that customers wouldn’t want to know, for example, interpersonal conflicts that might require a change of staffing in the team, but there are certain things that they simply don’t need to know about and might not want to be bothered with.

When you’re talking about communication within a team I got some very sage advice from somebody who was talking to me about gossip. Gossip is the idea that we’re just sharing our feelings or getting something off our chest or just venting. The problem, he said, is that when we talk about others to people who don’t have any authority to make a change, usually that happens when we’re venting to our friends or our coworkers, they can’t necessarily make a change, they don’t have the authority to.

I encourage you to think about who has the authority to make changes and fix problems and make sure that you’re not talking to people who don’t have the authority to very sensitive things.
Another group of people that you might talk to are evangelists and supporters. They’re not necessarily your customers or your management, but some people are excited about what you’re doing and want to spread the word to other people. I found that it’s important to share information with your evangelists and supporters. Not necessarily everything, but just enough to keep them excited and let them know that you’re getting close to your deliverable, that way they can stay excited about what you’re doing, start to talk to people appropriately before your product even delivered.

Decisions

You must understand on your team who has the final say. Here are some questions. Is the team leader’s authority clear? That’s a leadership topic that the team leader needs to understand whether it’s worth it to veto or not.
I’ve worked on teams where the team leader didn’t have the authority. The way I framed that is, the team leader didn’t have any teeth.

They could make certain decisions, but whether anyone actually respected those decisions or followed through with those decisions was questionable. They might have had authority on paper, but people weren’t following them.

What if the team leader gives or bestows the authority to other team members. In other words, they choose a few people on the team who can actually make final decisions on their behalf.

What about when your team meets with other teams? Who has the final say? Do the other teams have more power than your team? If the team leader, who has the authority, doesn’t go to those meetings is it clear that the people who have gone in his or her place have the same authority to make a final decision that the team leader has?

Going into politics, could it be that someone outside of the team is making the decisions? This could be good because people outside of the team might have more authority at the corporate level, but if they’re not involved in the discussions and understand what the problems are, they might make some very poor decisions. So decision making for a team can make or break the team.

These are the four major factors that determine the success rate of the team.

Thanks for reading.

Reasons Why Teams Fail

Saheed Oladosu — Sat, 05 Sep 2020 21:35:32 +0000

Let's get one of the big questions out of the way. Why are teams failing? Why do teams fail? Here are some reasons.

Misalignment of Vision

I think one of the biggest is that there's a misalignment of vision. For example, you might have worked on a team where your customer or the people outside of the team had an idea of what your team was going to produce. They might have thought, we hope for an awesome product delivered in nine months. Okay, I like the “nine months”, I don't like the “hope”, and I don't like the “awesome”.

How do you define awesome? What is an awesome product? As a team member you know that you want more than awesome, you want specifications. Regarding hope, I'm not saying that the managers or leaders can't be hopeful, but that should not be part of the statement of work.

On the one side, you have your managers or your customers who are hoping for something that isn't very well defined. On the other side, your vision will become much more clarified within the team.

Before the team starts doing stuff they have to figure out what they're working towards. What are the specifications of an awesome product? The problem with this is that even though you've defined what the awesome product is it might be completely misaligned with what your customers think an awesome product is. Aligning your vision is a critical part of team success.

Miscommunication of Expectations

Another reason why teams might fail is a miscommunication of expectations. Let's say there are various people involved in this project, whether they're on the team or they're customers of the team;

• We might identify some as the outside boss: this is the person who commissions the project,
• The team leader who is obviously on the team,
• Team members, and
• Then you have your customers.

You're not always going to have these four things. Maybe your outside boss is your customer, so you have these four types of people and they might have communications between them.

What are the expectations of each type of person? Well, the outside boss might be thinking, I just want the bare bones to get to market. I want a minimum viable product.

The team leader who's trying to do a good job at spiking the project might say; “oh, well we need to do A and B”. But the team members somehow understand that they need to do B and C.

Whether that's because the requirements weren't communicated very well or as a team, they decided that;

• A wasn't useful,
• B is useful, and
• Hey, while we're at it let's do C.

Because that would be pretty cool. Now we have three different expectations of what the result of this team would be.

Let's throw the customers in. They're not necessarily after a minimum viable product. They might not know about or want A and B or B and C, they really want something that might be completely out of reach like unicorn hair or something that's unreasonable.
I'm not saying that customers are always asking for unreasonable things; I just wanted to illustrate the idea of how different expectations can cause the failure of a team.

Disrespect amongst Groups

Of course, there are other reasons why teams might fail. If there's disrespect amongst any of those groups from the last slide, even amongst team participants, that can cause a team to completely collapse.

In a team environment, you'll have plenty of opportunities where people make mistakes and you'll need to forgive them. If your team harbors bad feelings and can't move on and forgive other people, that can cause a team to fail.

If there's poor leadership or management of the team, it might be impossible to succeed. Egos can get in the way of team success and if you have tasks that are simply impossible to accomplish or you're asked to do things without having the right resources your team is on the road to failure.

I'm not saying that any of these will surely cause team failure, but they sure make it harder for a team to succeed.

Thanks for reading.

Top 4 Reasons behind Building a Team

Saheed Oladosu — Sat, 29 Aug 2020 20:51:09 +0000

Why teams are even put together in the first place. You've heard the saying "if you want something done right, do it yourself." There are reasons why you might not want to do it yourself.

#1 The More Resources You Deploy The More Quality And Faster Results You Get

One of the most obvious reasons to have a team is because there's an idea that the more resources that you throw at something, resources being;
• More people,
• More eyeballs,
• More man-hours,
• More diverse skill sets, etc.,
We can accomplish something at a higher quality or faster. You know that's not necessarily true.

You've probably worked on teams where having more people or more time or more skills actually made things slower or lower quality or even caused the failure of the final product. But we do like to think that if we add more resources, then we can have something better.

#2 Synergy

Another reason why teams are put together is the idea of synergy. I know a lot of people don't like this buzz word “Synergy”, I love it. The idea of synergy is that you take two things, add them together, and you get more than the sum of the two things. In this case, the value of one person paired with another person is bigger than just those two. Working together they create more than two.

#3 To train other people

From a management and leadership perspective, one of the big reasons why you would use teams is to train other people. For example, if you put a cross-functional team together, not just developers, but maybe people from the marketing team, what happens is the developers understand marketing better, and the marketers understand development better.

That cross-training helps people understand the organization better and maybe understand the motives behind different departments. An example like that can also help strengthen the culture of an organization. Putting people together on a team that might not otherwise have ever worked together or even crossed paths in the hallway, having them solve problems together can strengthen relationships to lead to a more unified organization.

#4 When more people work on a product they work through the challenges

Another reason why teams bring value is that when more people work on a product they work through the challenges, they talk about the issues, they come up with solutions, and they implement those solutions, those people are more bought into the final product. They're even bought into the issues that the product is trying to resolve. You can imagine the ownership that those people have in the problems and solutions.

Understanding why teams are put together is of utmost importance to the upward movement of any organization.

Thanks for reading.

Project Management: What Exactly Is A Project

Saheed Oladosu — Tue, 18 Aug 2020 10:39:38 +0000

"Projects are similar in many ways but no two projects are the same." - John Babel

In project management, it's important to understand what a project is? What counts as a project versus what else might be part of our normal course of business? Well, there are a few unique characteristics that set projects apart from other sorts of work.

Projects always have a definite beginning and end

First of all, projects always have a definite beginning and end. This is true regardless of the length of the project. It could be relatively short, taking just a couple days or weeks to complete… or it could be much longer stretching into months or even years.

However, what's important is that there will be a specific date upon which we have started our work and at some point, once all of our requirements have been met… we will consider that work completed and we will wind down work on this particular project. Part of this is that both the process and the result of a project are unique. We're going to develop and follow a unique path to create a unique solution.

This is true even if we're working on projects that are relatively similar to other types of projects… that we've done in the past. For example, if we're in the construction business and we're building an entire neighborhood full of new homes… we may have many models that are very similar to one another… and in fact, the same model might be used for multiple houses.

However, we still are going to customize these for our customer's interests and their particular tastes. Some customers might want the exterior to be painted a certain way while others would prefer a different color. The same goes for the interior, or perhaps in the kitchen, we might choose a different type of cabinetry for one versus another… again, to help match up with those customer preferences.

Based on this information, we may find that a project is very similar in many ways… but no two projects are going to be the same.

Another key question is what exactly a project can create? We say that the process is going to be unique… what types of results might be the finishing point for all of our work on the project?
Well, this could include not just a new product, such as a new house or a new type of item or product that we're selling for our company… it could also include a product enhancement, some way to make something that's on the market right now better than it was before.

This could be either for external or internal use. So this could be a piece of software, for example, that we sell and release a new version to our customers… or it could be for a tool that we use within the organization ourselves.

We could also be looking to release a new service as opposed to a new product. So not something tangible, not a one-off transaction, but rather an on-going service that we can provide to either an internal customer… or someone external to the organization. We can also improve upon an existing service.

So we might have a pretty good cloud infrastructure in place right now, but we've decided we're going to add some more features, to help reduce latency, increase reliability by following some steps… that could be a project all unto its own or even several.

Finally, it could also be a new business asset that we create. Not a product or service… but instead something that the company itself can use moving forward. It could be a project for us to just go through the process of figuring out what type of new vehicle design we should come up with next… if we were a car company for example.

The different phases we would need to go through in that regard are;

· Where we have focus groups with customers.
· Where we get our employees together to understand what would be possible to design.
· See how we can leverage existing platforms.
· Where market demand is pointing us to for the next several years.

All of these different tasks could be considered a project of its own with the unique result at the end being a report… making our recommendation to be presented to the board of directors as to how we should move forward.

Projects require a purpose

In any case, whether it's a new product, service, business asset of some sort, or an improvement or enhancement on something that already exists… projects require a purpose to be initiated.

We're not going to do these for no reason. They have to be done to benefit someone for some specific reason. So it could be that we pursue a project in response to market demand.

Going back to the car company example, we may determine that we need to release a new SUV onto the market to keep up with consumer preferences, and so we're working to figure out how we can release that SUV… and then, of course, the project of designing and bringing to market the vehicle itself.

There could be a business need. This is often directly related to market demand… but think about some of the internal needs that could be met as well. It could be that our customer service system, for example, simply isn't up to par. It's not providing our employees with the tools and powers that they need… to best serve our customers. So being able to provide those tools to our employees is itself another type of worthy project.

There could also be a technical breakthrough of some sort that could lead us to start a new project. For example, if we develop mobile phones and new chipsets become available that are faster, that have better internet and wireless connectivity, and would allow us to introduce new and powerful features to users, we may decide that it's time to release a new model of our phone… and that, of course, will require a project of its own to design, develop, and deploy that to market.

There could be a customer order that serves as the trigger for a project being initiated as well. This is common in so many different types of businesses. We do work to specifically meet a customer's needs, and that also helps us to understand what the requirements for this project… to be considered successful might be right from the outset.

Finally, there could also be legal or regulatory requirements that arise. Let's say for example that we're in the power generation industry and we have determined that regulatory requirements are going to force us to phase out one of our existing power generating plants in the future… and replace it with something that's more environmentally friendly. Designing and deploying that solution could of course be a project all on its own.

Projects can take place at any level

Now projects can take place at any level of an organization, and any type of organization, whether it is a business, a nonprofit, government, etc., can of course seek to benefit from project management.

Projects could involve just a small handful of people or a much larger amount. So it could just be a group that we work with directly, it could be units within our organization or even a joint venture between several different companies or organizations… coming together to accomplish something big.

In any case, it's rare for us to know exactly what we're going to need to accomplish our project work from the outset… when we embark on it. Rather, project management plans are iterative. We may have some idea of what we're seeking to accomplish, for example, design an SUV to better serve the market… or create a new technical platform for our call-center staff.

These are areas where we might have some broad objectives in mind, but it would be exceedingly rare for us to go in and know exactly what steps we need to follow… in order to complete those objectives before we've even begun our project work. Rather, plans are progressively elaborated as new information becomes available.
Oftentimes we simply won't know what all we need to accomplish to meet our requirements… until we begin the work on the project.

That's how we can discover how we need to finish up the rest of it.

As such, project plans tend to look something like this, we're in phase 1 of the plan, what we're doing right now… we might have a very good idea of what needs to be completed, even down to the activity level.

For phase 2, we might have less detail, but still a pretty good idea of what objectives we need to meet.

In phase 3, we might have an even less clear idea, and then there might simply be a large pile of additional work behind that.

However, as we finish up phase 1, we should have more detail in mind for phase 2. In phase 3, we should have more of an idea of what needs to be accomplished than we did previously. We might even expand into an additional phase 4 that wasn't previously present. We still have some additional work to complete on the back end of that, but we continue to have an even clearer idea of what must be completed.

As we finish tasks, we're able to progressively define additional activities that we can then complete… until we've met all of our objectives on the project.

Thanks for reading. If you have further questions, kindly drop a message below or DM me on Linkedin @saheed-oladosu and I will respond ASAP.

How to Keep Your Mentoring Relationship Professional

Saheed Oladosu — Sun, 09 Aug 2020 18:18:20 +0000

When you're working with a mentor, it's only natural that sometimes your relationship can get casual. Here are some ideas on how to keep your relationship professional.

First, make sure that you always do what you say you will do. Your mentor needs to know that if you're going to have a conversation and you commit to something... that you'll actually follow through with that commitment. If you can't follow through with the commitment or you have a reason why it doesn't make sense anymore... then have that conversation, but if you commit to doing something, then do it.

As I mentioned earlier, if you're going to miss a meeting, that can be okay, but give me a heads up. Let me know that you're not going to be there so I don't spend my time going to a meeting that's not going to happen.

In our meetings, there will be a number of things that I ask you as the mentee to do. When you complete those things, I want to know. You don't have to wait for the next monthly meeting, you can send me a quick email... and say, hey, you remember this thing we talked about, I just completed it and here's how it went.

Throughout the month, as I get those types of communications, I'll feel confident that our relationship is going in the right direction... and you are in this to make progress.

Let me encourage you to use professional language. Again, it's easy to get into a casual relationship mode, and use language that you might not use in the office. Even though the relationship seems like it's getting a little casual... this is still a professional relationship. I encourage you to maintain that professionalism with the language that you choose to use.

Sometimes things can get stressful and emotional. It's okay to have emotions, but I would consider yelling a mistake. Definitely don't yell at your mentor, but even raising your voice... and becoming too passionate about a topic could be off-putting. Because your mentor is a volunteer, you don't have a strong position to demand that they do certain things. Be respectful of what they're giving to you. If you need a networking introduction, but they're not ready to make that introduction yet, there might be a reason for it. The last thing you should do is a demand that they make the introduction.

Also, because of how closely you'll be working with your mentor, there are going to be mistakes made. You might get stood up at a restaurant or they might have committed something to you by the end of the week... and not delivered on it. If you want to have a long-term relationship, I encourage you to be "quick to forgive".

Finally, remember that there are boundaries associated with them volunteering. At any point, they can say these;
• I've had enough, this isn't working out,
• This person isn't putting forth the effort,
• They're not doing the things that I suggest,
• They don't even listen to what I'm talking about, and
• They're hard to work with.

All of those things would be pushing the boundaries of your volunteer... and you can find yourself without a mentor very quickly.

Thanks for reading. If you have further questions, kindly drop a message below or DM me on twitter @saheed_olad and I will respond ASAP.

How to Ask Someone to Be Your Mentor

Saheed Oladosu — Wed, 05 Aug 2020 19:36:17 +0000

Let me start with this quote by John C. Shin - “Show me your mentor and I’ll show you your future”. And this is absolutely true.

In my posts on 5 surprisingly Effective Ways to find the right Mentor and 2 Stunning Types of Mentoring Relationship You Can Have... I discussed how you can find the right mentor and the two types of mentoring relationships you can have respectively. So, how do we ask someone to be our mentor?

Alright, let’s talk about how we can ask someone to be our mentor.

We've identified the person, and now we need to approach them and ask for this formal relationship. Before we do that, though, I want to talk a little bit about this quote, "the mentor relationship needs to be an active one".

As you think about your mentoring relationship... don't think about a once-a-month lunch that you're going to have with someone. This is a real relationship where we're putting in the effort, the mentor is putting in the effort, we're going to learn and grow. That can be painful at times. It's definitely going to be an active relationship.

Here are some things to think about with regard to asking someone to be our mentor. First, we should have a relationship with this person. Hopefully, it's one of our first degree contacts, but it could even be from an introduction from one of our first-degree contacts. You wouldn't walk up to somebody on the corner of a street and say, hey, would you be my mentor. That's asking a lot of someones who really have no idea who we are.

As you think about a formal mentoring relationship, you might want to think about starting small. Instead of committing to a 12 or 24-month relationship, maybe you ask for one meeting. That way they can get an idea of what your needs are and whether they could help you or not... and you can get an idea of their style and the way they respond.

Before you ask someone for a mentoring relationship, you should know what you want. The more you can define this, the better that conversation will go when your mentor says, well, what are you looking for and how do you think I can help you? I encourage you to actually practice inviting the person to be your mentor. This is a serious commitment that you're getting into and asking them to get into. Why not take some time in front of the mirror or with 3 x 5 cards to practice how that conversation is going to go.

When you ask someone to be your mentor, you'll need to help them understand the scope of what you're asking them for. You're not asking them to come to your office every day or every week, maybe you're simply asking for that once-a-month check-in.

Helping them understands their role and the scope of the relationship can help them know whether this is something they can commit to or not. Also, they need to know that you are ready and willing to work. This mentoring relationship isn't necessarily about them... although they should get plenty of value from the relationship, this is about you.

You have objectives, you have a problem, you need help, are you really ready to do the work? Make sure they know that you are ready. You should be ready for them to say "No". They might already be too committed or really not understand the value of a mentoring relationship for them.

If you ask someone for a relationship and they turn you down, I wouldn't take it too hard or take it personally. Maybe their circumstances will change later or for now, someone else might be a better fit.

Essentially, you are trying to sell them on this relationship. Because of that, you might want to think about what the value will be for them. What are they going to get out of being a mentor?

Think about that and have some responses prepared so that you can have a better conversation. Here are four parts of the conversation you might have when you ask them to be your mentor. Because the order can be mixed up, I didn't number them 1 through 4. Instead, I've used A, B, C, and D.

A. Why you want to have the relationship

One of the elements of your request is to present why you want to have a relationship.
This might look like this;
"I feel kind of stuck in my career right now... ", or
"I want to get to the next level of my career..." or,
"I know I need a guide to help me through this situation... ". Basically what you're doing is you're setting out the reason why you need a mentor.

B. What their role would be

The second element is to explain what their role would be. For example;
"I'm looking for someone who can help me..." do a certain thing, "I think it's time to sit down with someone once a month... ".

What this would tell me is that you've already done a certain amount and feel like you've maxed out what you know how to do, and now you need to bring somebody in.
Or, you put it all out on the table and say, "I'm looking for someone who can mentor me... ".

C. Where you explain your commitment or the idea that you're ready to work

The third element of this conversation is where you explain your commitment or the idea that you're ready to work.
You might say, "I know it will be a lot of work on my part, and I'm ready..." to do that work.
Or you might say, "I'm committed to doing what it takes to get there... ".
Or you might say, "I plan on spending a lot of time to get... ", and then whatever the objectives are that you've already lain out.

D. When you actually ask them if they would be your mentor

The final part of this conversation is when you actually ask them if they would be your mentor. You might say, will you meet with me as a mentor for the next three months or you could say; "Are you open to being my mentor to help me...” Work through these problems.

Or you could say, "Will you help me by being my mentor and guiding me..." as I work towards my next promotion.
I've given you four different elements of this conversation.
In summary, present the reason why you're looking for a mentor, explain what their part would be, explain your commitment... let them know that you're ready to work, and finally, ask them if they will be your mentor.

Now the question is, should we do this on the phone, should we do it in email, or should we do it face-to-face?

I would prefer the meat of this conversation to happen fact-to-face. I think that's the best way to do this, however, that's not always going to be possible. You can do this on the phone or in email or face-to-face. Whichever way you choose to do this, just make sure that you have some kind of relationship... and are ready to have the conversation that would include the four elements that we just talked about.

2 Stunning Types of Mentoring Relationship You Can Have

Saheed Oladosu — Sat, 01 Aug 2020 16:01:22 +0000

In my post on 5 Surprisingly Effective Ways to Find the Right Mentor... I discussed what you need to do to find the mentor that’s right for you. In this post, I will differentiate between the two types of mentoring relationships you can have.

Digging a little deeper into what it means to be a mentor... let's differentiate between a formal mentor and an informal mentor.

The formal mentor knows about the relationship. This is someone that you've approached and in one way or another have invited them to be your formal mentor. They've agreed to this relationship, and they know what their role is in the relationship. You've also had a conversation about the expectations of the relationship. They know what the expectations are and they agree with those expectations.

In a formal mentoring program, you'll typically have regularly-scheduled sessions with the mentor. Whether that's every week, every other week or once a month, these are scheduled out for quite a while. Typically, a formal mentoring relationship is a long-term relationship. Let's contrast these with an informal mentor.

An informal mentor might not even know that you consider them your mentor. Over the years I've heard someone talk about people who they consider a mentor. They never had a formal mentoring relationship, but they learned things as if that person were mentoring them. In an informal relationship like this, there aren't necessarily regular meetings.

You can have meetings, you can go to lunch, you can have phone calls, whatever type of meeting you want to have, but they're not scheduled out over the next year. You might not ever talk with or meet your informal mentor.

You might just read a column they write or listen to them on the radio. Because you don't have a formal relationship set up with them if you have the opportunity to talk with an informal mentor... and ask them for feedback on a certain situation, they don't have any obligation to give you honest feedback.

There isn't necessarily a relationship of trust built... and they might not have enough information to really give you honest feedback. If you do have a meeting with an informal mentor, there is no obligation on their part to prepare... or even think about the meeting before you sit down with them.

Finally, you don't need to have a relationship with someone in order for them to be an informal mentor.

If you have further questions, please drop a message below or DM me on twitter @saheed_olad. I will respond as soon as possible.

5 Surprisingly Effective Ways to Find the Right Mentor

Saheed Oladosu — Mon, 27 Jul 2020 21:28:02 +0000

This is a quote by Richard Benson, that's important for anyone who's looking for a mentor to internalize. It says, "A great match for one person may be a bad match for another."

Don't look at another person's mentoring relationship and think... oh, if only I had that person as a mentor or if my mentor was like that. Here are some considerations to think about as you look for a great mentor.

First, start with YOUR needs. Try answering the following questions;

What is it exactly that you're looking for?
Does it have to do with progress in your career?
Does it have to do with progress in your own company or in the industry in general?
What are the things that you're hoping to get out of that relationship?
Do they have the time or interest to volunteer as your mentor?

These are five considerations to think about as you look for a mentor that will be right for you.

Identifying your needs will help ensure that you find the right mentor to help you meet those needs. You should find a mentor who has done what you want to do. They have already gone down that path, they know what it looks like... and they can help you navigate that path because they've been down the path.

Developing chemistry between you and the mentor is critical. If you feel like there's something missing in the interpersonal relationship before they're your mentor... you might ask yourself whether you think that can change or not. If the chemistry will never be there, it might not be a good match.

In addition to chemistry, personalities are really important. Some people are very abrupt with their feedback and they can come across as offensive. They're not necessarily trying to offend you, they're just trying to be very honest.

I'm not suggesting that there's going to be a right or a wrong personality match for you... but if you do feel like there's tension in the relationship, you might want to study up on personalities to see what the difference is between their personality... and your personality, and how to work together and communicate better.

Of course, when you think you've found the right mentor... you need to make sure that they're actually in a place in their career where they can, and they're willing, to help you.

So now, where can you find someone to be your mentor? Start off with who you know. Who is in your network that you think would be a great mentor for you?

As you brainstorm names to be your mentor, what I don't want you to do is disqualify people... assuming that they wouldn't be your mentor. Write everybody down on a list without already deciding whether they want to do it or not.

Once we have a list, we can prioritize the list and work down that list, but don't automatically cross people off. In addition to who you know, people in your first-degree network... think about people that you could get an introduction to, or who are people that your first-degree contacts might know.

Obviously, you can use LinkedIn to dig deeper into your network, including your first-degree contacts and beyond. Don't discount other social networks like Facebook or Twitter.

Typically people don't go onto Facebook or Twitter because they want to be a mentor or even have a professional relationship with you... but if you have connections on Facebook or Twitter or other social networks... those might be people who can be a mentor or introduce you to someone who could be your mentor.

Also, ask your colleagues and the people you work with. You might ask questions like;

• Who do you admire in our company?
• Who do you think has had a great career?
• Who has helped you in your career?

These are three questions that you can ask your colleagues to get some great ideas... for who the right mentor might be for you.

How to Learn New Technologies Quickly

Saheed Oladosu — Thu, 23 Jul 2020 11:51:48 +0000

There's something about having to explain to someone a concept that makes it clearer... and easier understood by the teacher during the process. Don't believe me?

Try this simple experiment. The next time you go to an event or a training session or watch an online course. Watch it as if your responsibility was to teach it and explain it to someone else afterward. And do just that.

Make a presentation of it and present it either to your team, to a friend, or your significant other. You will see that your level of attention and your focus will be two or three notches higher than before. And this is not a new principle.

Again, we can go back to antiquity with Seneca who said, while we teach, we learn. Recent studies show that students who teach others score higher, this being called the protégé effect. And there are many factors that lead to this.

For starters, your circle of influence significantly increases... when you are responsible for someone else understanding the information you share. Also, you will look at it from multiple perspectives and identify several ways to transfer your knowledge. That again gives you a much higher level of understanding of the concept.

Finally, you're emotionally linked to your students getting satisfaction when they understand your explanations... and being frustrated if they don't. And teaching doesn't need to be solely in this traditional form... teaching can be posting a blog post where you share your experience on a specific problem. Teaching can mean publishing a plugin, toolkit, something that will help others solve a problem or avoid it altogether.

There is no better way of understanding a new concept than sharing it with someone else.

How to Be a Better Software Developer

Saheed Oladosu — Sun, 19 Jul 2020 13:50:05 +0000

If you look at the world of business or tech at the core what every company solves is a problem. The need that the end users sometimes didn't even know they had.

That's why this principle is extremely effective in your search to have relevant skills and stay ahead. Your learning efforts are much more powerful when they have a clear purpose. If you're at a point in your career where you've already mastered the language... let say Javascript, then you should focus on optimizing it. If you're just starting out, no problem, there are tons of projects you can use as practice.

Karan Goel, an engineer at Google, compiled a mega list of projects that you can solve in any programming language to get started. You can find it on GitHub.

You have everything from numbers, classic algorithms, graphs, data structure, networking, classes, threading, files, databases, graphics, and security. And I'm sure you can find something similar for any industry you're in. So if you don't know where to start, try something like that.

Another option is to build your own project that will make life easier when you do another task. Build tools that will help you later.

In my opinion, the reason why most people quit learning or stay as a newbie after two years of learning how to code... is not solving the right problems that will improve their learning.

Long story short, remember that the fastest way to learn and grow is to have a clear goal on what problem you want to solve.

Why You Need a Mentor

Saheed Oladosu — Wed, 15 Jul 2020 12:37:26 +0000

Since Greek philosophers, the value of a mentor has always been underestimated. 2000 years later the rules still apply. A mentor, or at least emulating someone... who is now where you want to be at some point in the future, is the fastest way to success.

A mentor will laugh at problems you consider impossible and it will speed up your learning process... and make it less frustrating and more challenging. Ideal mentors are colleagues, preferably more experienced than you... but also people that you can frequently interact with either offline or online.

In my next post, I'll talk more about how to get the most out of your mentor without being disruptive to his or her schedule. In case you struggle in finding one or you don't feel any form of synergy with the ones that offered to coach you... an alternative is a community of like-minded people... where different perspectives and backgrounds will help you solve problems faster.

You can find these people either on blogs and forums. But the most effective way is to either search for or establish a local community... and have weekly or monthly meet-ups. The exchange of ideas will help you to stay on track with industry changes, new technologies, and can even offer career opportunities.

As a newbie, having a good mentor will speed up your learning process... and can at the same time open a lot of opportunities to you.

Leave a comment below. If you like this post, please share.