5 Ways to Structure a One-on-One and Why It’s Important

Reading Time: 2 minutes

I have always been a big proponent of spending time with your employees. In my last post, Gift Your Time, I went into reasons for considering your time as “not your own” when it comes to leading employees. In this post, I plan to define the One on One, talk about why it’s useful, and give some tips on how it should be structured.

What and Why

So what is a One on One? A One on One (or O3) is exactly what it sounds like. It’s time set aside for a one on one meeting between supervisor and employee.  Subject matter can vary from employee growth to home life. It’s an opportunity to strengthen relationships and provide career coaching.

If you are a leader, it could be the most important tool in your toolbox. Here’s why: in a 2014 study conducted by LeadershipIQ, over 32,000 employees were surveyed with regards to the time they got to spend with their leader. In this study, it was found, time with their direct supervisor had a direct correlation with the employee’s engagement. More specifically, the study showed that employees who got more exposure with their direct supervisor felt 29% more inspired, 30% more engaged, 16% more innovative, and 15% more intrinsically motivated. In other words, this study is proof of ROI should you decide to invest your time in your employees.


1)      Frequency – The frequency of these meetings are up to you, but there should be a frequency. Make sure to schedule a reoccurring meeting, and make it a priority. I can tell you from experience, if you miss these meetings, your employees will notice and remind you. I schedule with my employees every two weeks, and on the rare occasion I need to reschedule, I always make up a missed session.

2)      Duration – This is also up to you, but make sure this time does not feel rushed. Meeting with your people should feel like quality time, not a task. I started off with 30 mins but quickly learned that my group wanted to talk longer. I now hold 1 hour O3s, and we seem to cover mostly everything.

3)      Structure – Build a structure around the meeting. I usually open up by asking if they have anything specific to talk about. After that, I ask them about their home, work, and their home/work life balance. I like to end with something that promotes their career growth and development by coaching them on a particular behavior. Yours may vary, but this is a good starting point.

4)      Preparation – I always come prepared with talking points for each of my programmers. As the leader of the team, I am also the coach, so I like to make sure I can use this time for professional coaching if needed.

5)      Engagement – I ask all of my developers to be engaged during this time. I request that they bring items to me as this is a mutually beneficial meeting. Rarely do I have instances where they don’t have something to discuss.

I truly believe that this practice is a fantastic way to promote growth for both you and your employees. If you haven’t already, I encourage you to read my last post. What are some of your success stories? Please leave them below. Now, go put someone in a position to be successful!

Link to referenced study: Optimal Hours With the Boss

Share This:

Gift Your Time

Reading Time: 3 minutes

What if I were to say that I gave a local charity one thousand dollars? What would be the response? I imagine people would think it gracious, give me a pat on the back, and go on with their day. Now, what if I said that I spent a full day tutoring kids at a homeless shelter? Once again, I think I would get the same response, but it might end with a feeling of motivation. A sense of maybe “I should do something.”

This is interesting because, on paper, these two efforts are not equal. My time is nowhere close to being worth one thousand dollars. In fact, with that money, they could have hired a full-time tutor for two weeks. So why would the second scenario invoke the same, or possibly greater, emotional reaction than the first?

The answer is that time is a non-renewable resource. People recognize that money comes and goes, but time is a gift that can’t be regifted. That’s why, in the office, it is so important to be available to your employees. Your presence/absence doesn’t go unnoticed. It plays a role in the daily culture of the team. It impacts moral, happiness, comradery, etc. If you want a productive, happy, and passionate team, make yourself available.

I do this in a couple of ways:
Interact Face to Face – This is priceless. My team works in an open office environment, so I make sure my desk is right in the mix. When I’m onsite, I encourage my group to interrupt me at any time. When I’m offsite, I try to converse via video chat. This is much more intimate than email or traditional phone calls.
Schedule Time Regularly – Every two weeks I set aside an hour for every team member to get a pulse on the team. I use this time to get to know the individual as well as provide coaching as needed. My next post will dig deeper into this platform.
Provide Undivided Attention – When I am talking with one of my employees, I make sure to stop doing anything else. I don’t check emails or flip through my phone. I make them the priority. If you don’t do this, they will see that they are not the priority, and that will change your interactions in the future. If you need to finish what you are working on, it is much more respectful to ask them if you can finish. It has been my experience that no one will have a problem with that.
Don’t Appear Busy – This is probably the hardest one. Being a good leader means you are busy. However, if your employees are constantly exposed to how busy you are, they may feel hesitation about disrupting you. I recommend that if you want time for zero disruptions, use your calendar and block off time slots for focus. All other time encourage interruptions. Your team will be very responsive to this.

Time is the best gift you can give to your team, but it’s also sometimes the hardest commodity to come by. Time is scarce but the real truth is there wasn’t more of it yesterday than there is today. There is still the same number of minutes today as there will be tomorrow. The difference isn’t time, it’s priority. If you want to make time for your employees to raise morale and happiness, you need to make it a priority. Can that email wait until tomorrow? My guess is that it probably could.

Thanks for reading. If you have any experiences you would like to share, I would love to hear about them. Please leave them in the comments below.

Share This:

Share Your Ideas

Reading Time: 3 minutes

Sharing ideas at the office isn’t as easy as it seems. Despite the many modes of communication, without a formal “brainstorming” or “Idea Generation” meeting, most ideas won’t get discussed. This increases the likely hood that ideas will be reactive, decreasing your odds at innovating. I’d like to talk about some ways that you can encourage these types of discussions regularly in your organization, changing the conversation from reactive to proactive. In this article, I will go through an example and some lessons learned as we set out to solve this problem.


TED is the obvious front-runner in idea sharing. Their slogan is even “Ideas Worth Sharing.” They invite influencers from every industry and broadcast the talk for all to see. But what makes TED so successful? Is it their presenter line up? Don’t get me wrong; the presenters are nothing short of amazing. But why would already renowned industry influencers choose to use TED to communicate their message? The answer is that TED is a platform designed to be a megaphone to the world.

So what can we learn from TED at the office? Simply put, build a platform. If sharing ideas is a value to you, then make this a priority. You could start by setting aside 15 minutes at your weekly meeting to allow for an employee to educate the group on something they learned this week.

This is how the company I work for started. Fast forward 3 years and we now have a 1-hour time slot every 4 weeks for 6 presenters. The megaphone we built goes to the entire company including a live stream to two of our offsite locations. My last post Leader-Leader is a presentation I gave at our last platform (we call it Tech Faire).

Lessons Learned

Start Small – to build something for an entire company can be very expensive. The risk is much less when you can build it up with a smaller team (especially if individuals are passionate). We started with about 15 people and it slowly grew to a company-wide platform.

Create Creative Boundaries – Content for your platform needs to have quality. You don’t want speakers talking about a topic for 30 minutes. People can lose interest. TED has a presenter rule of 18 minutes. We took it a step further and limited speakers to 6 minutes and 40 seconds (20 seconds per slide). We require all our presenters to present in a 20×20 format or PechaKucha. This keeps things flowing and people engaged.

Build up the Presenters – Don’t only choose people who present well. Everyone has an idea that can bring value to the organization. If someone is uncomfortable with presenting, offer options like practice runs or a mentor. The presenters are investing their time in the audience so they should also feel invested in.

Bring in guest speakers – See if someone from outside of your direct team or organization will share something with you. Outsiders bring a fresh perspective and energize the room a little bit more.

Expect Naysayers – Like all change initiatives, there will be opposition. It usually comes in the form of concern with time and how it’s being spent. My advice is to mitigate the risk by “Start Small.” Grow your tribe and invite the naysayers to an event. You will be surprised at the turn around some will have on the idea.

Wrap Up

It’s been my experience that everyone has something interesting to share. My company has been doing this for over 3 years and every month is more impressive than the last. This has been one of the most rewarding initiatives I have been a part of and I truly believe there is a potential platform in every organization. If anyone has an experience they would like to share, please feel free to comment below.

Share This:

Leader Leader

Reading Time: 5 minutes

I gave a presentation to Associated Electric Cooperative Inc. Aug 26th regarding a topic I have become very passionate about: Leader-Leader. The recording of the presentation is below. I got the story from 2 books. Leader’s Eat Last by Simon Sinek and Turn the Ship Around by David Marquet. The sound quality isn’t 100 percent so I have a transcript below for those who would rather read it. Enjoy.


Our story starts with a man named David Marquet. He was a career submariner who finished top of his class in almost every category. One area that David Marquet excelled in was Leadership. As such, he worked his way up the promotion ladder until he received the greatest honor a navy man can receive, command of his own ship.

The now Captain David Marquet was to be command of the USS Olympia. This was a very prestigious sub. To prepare, he takes the year prior to his command and dedicates it to learning every component of the sub, including the crew. He believed that in order to gain the respect of his crew and to do his job well, he needed to know as much if not more than the crew themselves.

However, two weeks before taking command, Captain Marquet receives a call. In that call he learns that he will no longer be taking command of the Olympia, but instead the USS Santa Fe. The Santa Fe was a newer sub but not extremely different. The crew however, was another story.

The crew of the Santa Fe ranked last in nearly every readiness and retention category that the US Navy had. It was so bad that real life scenarios from the Santa Fe were used as bad examples for general Navy training. But that was ok. Captain Marquet was confident in his abilities and was up to the challenge. The Navy had shown him that Marquet would be a leader because he was given control. So it was easy for him to believe that if I give good orders, I will have a good ship, and if I give great orders, I will have a great ship. So Captain Marquet took control of the Santa Fe in January 1999 knowing that he had an uphill battle.

Fast forward a few months…Captain Marquet, after getting more comfortable with his command, decides to run a drill while out at sea. The simulation was a reactor failure (basically an engine failure). It was a standard drill, nothing out of the ordinary.

Everything was going well. The sub was running on battery power and all the crew was working on restoring the reactor. So Captain Marquet decided to shake things up for the crew. He looks to the officer on deck (the most experienced officer) and says “Ahead 2/3” meaning move forward at 2/3 the maximum speed. This would drain the battery faster and increase the urgency of the crew to get the reactor fixed.

“Ahead 2/3” the Captain said

The officer on deck confirms by saying “Ahead 2/3” to the Helmsman.

Buy nothing happened. The direction of the sub and the speed remained the same. So the captain looks at the helmsman and sees him sitting very uncomfortably in his chair and asks, “Helmsman, why did you not execute the order?”

The helmsman replied, “Sir there is no 2/3 setting.”

The ship that Captain Marquet had studied for had a 2/3 setting. The ship he was on did not.

Caught off guard by this he turns to the Officer on Deck and asks “Did you know there was no 2/3 setting?”

The Officer on Deck replied “Yes Sir.”

Caught even more off guard the Captain asked “Then why did you issue the order?”

The officer simply replied “Because you told me to.”

It was at that moment that Captain Marquet realized that he was trained for another ship and his crew was trained for compliance. In a sub this was a problem with dangerous consequences. He was getting comfortable issuing orders and his crew was getting comfortable blindly executing them. He was reinforcing a hierarchy that he questioned his entire career. He refers to it as the Leader – Follower.

In the leader follower dynamic Captain Marquet started to see a truth. He States that those at the top have all the authority and none of the information and those at the bottom have all of the information but none of the authority.


From this point forward Captain Marquet vowed to keep his mouth shut when he was on board. He wanted to turn the dynamic from 1 commander barking orders at 135 passive followers, to 135 active passionate and engaged leaders, proud and motivated about what they were doing. In order to do so, he needed to change from leader-follower to Leader-Leader.

In his book, Turn the Ship Around, David Marquet describes several practical steps he took to get here. One major step was to ban the phrase “Permission to”.

“Sir, permission to submerge the ship?”

“Premission granted. Submerge the ship”

He replaced this phrase with “I intend to”.

“Sir, I intend to submerge the ship”

The shift here is a psychological one. The chain of comman is still in tact but when initiating the command, the person that is performing the action now feels a stake in the outcome. It’s now coming from an area of intent instead of a passive task to be carried out.

Captain Marquet even took it a step further as he too didn’t blindly approve all “I intend to.” He would often find himself asking several questions before approval. So he started asking his crew to not only come prepared with what they intend to do but why they intend to do it. What he found was not only did he not have to object to many proposals, but he was correct in his assumption that the crew had the knowledge needed to make these types of decisions. They just needed a chance to vocalize them.

As an added benefit, this change caused all his crew to start thinking at the level above them. The officers on Deck had to think like the captain and so on down. This was important because the crew were literally acting their way into their promotions. This turned into a very effective leadership program.


Trust and cooperation of the crew improved so much that once the lowest ranked crew in the Navy, now they became the best ranked crew in Navy History. Before Captain Marquet took command, the reenlistment rate of the Santa Fe was 3. After he took command, it was 33. The Navy average was 15 so there was an obvious morale spike.

As for the leadership program, on average 2 to 3 commanding officers typically get promoted on a ship after tour. The Santa Fe promoted 9 of 14 officers to go on and Captain their own ship.

So what did we learn? Captain Marque was able to do this by resisting the temptation to absorb more power. When faced with the decision, he decided to not be the smartest person on the ship rather empower those around him, letting his crew feel responsible for the success of the ship.

If this topic is interesting to you, I would like you to remember 2 questions:

  1. Do I typically ask permission or do I make recommendations?
  2. If I am in a position of power, do I typically solve my people’s problems or do I empower them to solve their problems on their own?

I hope you enjoyed the presentation. If you have any feedback or stories of your own, I would love to hear them. Feel free to leave them in the comments below.

Share This:

Leading by Following

Reading Time: 2 minutes

Being a leader is a difficult goal to strive for. People say leadership takes courage, character, confidence, charisma, etc.… and they aren’t wrong. However, when defining a leader, people tend to miss the true defining characteristic: someone needs to follow. A leader isn’t a leader if they are leading no one. One could make the connection that a leader is only a leader if they were leading someone. Profound stuff I know, but at its core, the statement is extremely accurate. Any leader of value has always needed one person, and that person is known as the First Follower.

The First Follower is an underrated form of leadership. The leader typically gets the majority of the credit but it’s the First Follower that often finds themselves unknowingly determining a leader’s success. In his TED talk “How to start a movement”, Derek Sivers states that “the First Follower is what transforms a Lone Nut into a Leader.” He continues by showing a video of a lone dancer. At first glance, it is obvious that the lone dancer is very courageous, but also a bit awkward. About 10 seconds in, one person gets up and starts dancing alongside (First Follower). It only takes a second for the First Follower to start encouraging his friends to join. Around 30 seconds, dozens of people are out dancing along with more running into the group every second. With the combination of the Leader and the First Follower, they were able to start a movement within minutes. Below I outlined some responsibilities for the Leader and the First Follower to make this work.

The Leader – Although it takes a strong amount of courage to put yourself out there, its takes almost an equal amount of courage to be the first one to stand up and follow. That is why the moment you receive your first follower, its critical to raise that person up and accept him as an equal. The message must change from “follow me” to “follow us.” Future followers need to trust that everyone out there is in this together. It’s the leader’s responsibility to limit the risk to his follower while enforcing the belief that “we win together, or we lose together, not separately”.

The First Follower – You have taken a risk by being the first one to join your leader. Your job from here is to encourage the people who trust you to trust the leader. At this stage, you are now a leader yourself, so all the above statements apply. Build up anyone that decides to come along, and encourage them to encourage others. When you do, you will instantly see the impact you had on the movement.

As a closing thought, I want to encourage everyone to keep an eye out for an opportunity to be someone’s First Follower. I won’t lie, it may be hard depending on the change you decide to stand up for, but it just might be one of the most rewarding experiences you have. Not to mention it could be the only thing standing in front of success for the leader. I also encourage everyone to watch Derek’s video below. It has heavily influenced my way of thinking. And of course, please leave me comments if you have any insight to share.

Share This:

Finding Predictability in an Agile World

Reading Time: 6 minutes

Agile, it just might be one of the biggest buzz words in Software Development. It’s right up there with usual suspects like Big Data and Synergy. And it should be. There’s no denying that Agile software development practices have revolutionized the industry. By valuing speed of delivery above all else, “The Agile Manifesto” has attracted a wide community of followers and continues to grow in popularity. And no, I do not mean a manifesto that is both fast and easily changeable, as the title would suggest. Developers have started using Agile as a noun instead of the adjective. This allows for silly sentences like “We need more Agile” to not only be grammatically correct but make sense in certain circles.

Based on the popular proclamation “The Manifesto of Agile Software Development”, Agile Software Development was conceived around 4 key values: Individuals and Interactions over Processes and Tools, Working Software over Comprehensive Documentation, Customer Collaboration over Contract Negotiation, Responding to Change over Following a Plan[1]. To a true believer, this is the only way to be successful. I have read books comparing Agile Vs Predictive methodologies where Agile was given the title of “value driven”[2] while Predictive was written off as overhead and unlikely to succeed. Many of these books are written by industry leaders, some of which I consider mentors for my career. After reading these books and articles, I still have one question that seems to be overlooked by most in the industry: How can agile practices add value if a core value of the customer is predictability? Is there a method that allows for Agile practices to work hand and hand with Predictive practices? In this article, I will explore the background that brings up the question, my Team’s solution to the problem, and some lessons learned along the way.



I have a small sized team that works as an internal IT shop. The team consists of myself (team supervisor), 4 developers, and one part-time intern. We are responsible for 3rd party software implementations, 1st party app development, and general support for everything we push to production. Seeing as we don’t have a full time project manager on staff, the developers are responsible for the management of their projects. They pick the style of management that best suites the problem and by no surprise, almost all projects involving app development typically end up following an Agile implementation process. Some developers might have the kickoff and the first line of code written in the same day.

Why is this a problem? Well at its core, we are adding value to the business at a speedy rate. By diving right into the code, we are able to get a first release within 1 or 2 weeks (Continuous Delivery Coming Soon!). However, the speed is countered by the unchangeable truth that software is never complete, only abandoned. Even though we have speed of delivery on our side, when is the project complete? This is the question that our customer base is interested in.

Two years ago, we had 3 large concurrent apps being developed by my team. Each release brought these apps to a stronger state of usability, but they just seemed to continue for months. With each release, the users wanted something else. Whether it be an enhancement to the application or a requirement that was originally overlooked, the priorities kept shifting. As a result, the discussions quickly changed from what we are delivering, to what we are not working on as a result of not “closing” the project. Despite shipping customer requests at a fast rate, we were getting a reputation of being slow and stagnant. Our customers all but demanded a change in the way we did work for them. Considering that we have seen pure Predictive methodologies fail just as often, the solution called for a different approach.



The solution we are using, I’m calling Predictably Adaptive, and the key value is this: Enable others to make value decisions within an expected limit. I recently read Creativity Inc. where Ed Catmull discussed this very subject. He described a room with popsicle sticks on the wall. Each stick represented a “programmer week” of work (hold your jokes please). They went through assigning popsicle sticks to each item of work, resulting in a time line for completion. Ed referred to this as a creative limit. The way this worked is, if someone recommended a new feature that would take a programmer week to implement, instead of being strict on the schedule or lax with the man power, they would simply ask “What stick would you like to use for this feature?”. This suggesting that if we want this feature, another feature may need to be delayed[3].

Our implementation is not much different from this. We start the project off with heavy planning instead of instant code. A schedule with target dates is composed and we begin to iterate changes to the customer in a quick fashion. With every release, we encourage a feedback loop that allow the customer to recommend additions/changes. At each loop the developer provides an estimation and enables the customer to make decisions based off the current target dates, project progression, and new estimates from the developer.


With this information there are 3 typical decision points at each feedback loop:

  • Replace a time equivalent feature on the project list with the newly suggested feature (stay on timeline)
  • Add newly requested feature to future enhancement wish list (stay on timeline)
  • Add newly requested feature to the list and extend the target dates accordingly (alter timeline)

All options are acceptable decisions and can only be made if the project manager or developer educates the customer of the impacts. Where previously these decisions were being made in the dark and most of the time by the developer, we have found by empowering the customer to make informed decisions they have more ties to the final outcome and allows for the developers to only deliver on highest priority items. Since implementation, we have seen an increased turn around on highest priority projects and we are steadily regaining our reputation of being a “quick to deliver” team.


Lessons learned

Programmers by nature are more interested in coding than planning. This isn’t exactly a profound statement I know, but this is something that caused some conflict from within the team during the change. To developers that are used to Agile methods, planning seems like wasted time. It seemed like any suggestion other than Agility was viewed as equivalent to a Waterfall style of project implementation (zero feedback loops). So it did take some effort to get everyone comfortable with the proposed change. I was able to accomplish this in a couple of ways.

  • Communicate the why – I took a lot of time to educate the team on why we are making the change. To them, when I advocated for more thorough planning, they all thought I was ready to take the team down the road that gave rise to Agile methods in the first place. To gain the team’s trust and build their confidence in the plan, I was completely transparent with the problem we were trying to solve. By sharing the values and perception of our customers, the team became more inclined to change things up making the transition much easier. Their openness was necessary for a smooth experiment.
  • Be intentional with the vocabulary – Make sure that both the developers and business partners know that we are not setting deadlines, but instead we are declaring target dates. This is an important distinction. Deadlines can be extremely dangerous due to an assumption that a deadline cannot move. When dates don’t move, that causes developers to cut corners and sacrifice quality to meet the objective. This typically is a lose-lose situation. Targets on the other hand are understood to move. If you keep your eye on the target as you get closer, you will be better equipped to handle the “unknown unknowns” when they arrive. All you have to do is understand where the new target is and continue to move forward. Education of this difference is absolutely key.
  • Encourage the customer to have a stake – When it’s time for a feedback loop, make sure the business partner knows what to expect. Educate them on the process and encourage them to not only provide free feedback but also to participate in the decision making process that may follow. This allows the business partner to understand what the scope of the request is and possibly come up with a creative solution to get to the ideal outcome. This strengthens the relationship and can improve the overall quality of the project

Overall, I am excited with what the team has been able to accomplish over the last year and a half with this implementation. The product output has been great and our customer relationships get better with every release. I cannot guarantee that the solution has scalability. However, for a medium sized, lean, internal development team, having the power to make decisions based on predictability has been a powerful tool and something we have been building success around. If others have solutions for the same problem, I would love to hear ideas or feedback from your experiences so please leave me a comment below.


[1] http://agilemanifesto.org/

[2] Agile IT Organization Design by Sriram Narayan

[3] Creativity, Inc. Overcoming the Unseen Forces that Stand in the way of True Inspiration by Ed Catmull

Share This: