AKF Partners

Abbott, Keeven & Fisher PartnersPartners In Hyper Growth

Tag » leadership

Top 5 Posts

We love data and think most things should be data-driven, as is evident from our newest book that reveals how successful companies learn from customer misbehavior. This isn’t done by asking customers what they want but rather by watching them through monitoring, logs, and alerting. This concept is summarized nicely in this article we published last month. In that vein, we keep track of how people read and use this blog. In this post we thought we’d share some of the most popular posts. Here are the top 5 posts that people have been reading:

  1. The Future of IaaS and Paas
  2. JAD and ARB
  3. Dealing With Shared Services
  4. Be A Leader
  5. Fault Isolation

Not too surprising, our readers are interested in how to scale via clouds, better architectures, and improved processes. They are also interested in leadership, since without that scaling a great organization becomes impossible.

Let us know what your favorite post is. You can find a list of all our posts here.


Comments Off on Top 5 Posts

Driving Change

Driving big changes can be difficult in an organization and it can be especially difficult for new managers. Change is necessary and we should never be happy with status quo as our competitors and the overall market is changing around us. The larger the organization, the harder change can be. We touched on this in an earlier blog titled Five Leadership Lessons From Former Bosses but decided to dive into a little more detail this time. As a former manager of engineers and other talented technologists, I recall in my early days how I simply wanted to identify where we were headed with my team without giving them time to collaborate and provide input. On one occasion, we were in the midst of changing our PDLC to Agile. Agile was fairly new at the time so many didn’t understand the basis of it and in turn were resistant to using it. That problem is easily solved, right? I could just tell the team this is where we are going and this is how we are going to do it, now make sure you execute. And in a couple weeks time, poof, the change would be made and life would be good. After all, that would have been easy, right?

Although I didn’t say the words “get onboard,” I might as well have. I can tell you this doesn’t work well. My team was zapped. At that point they were no longer empowered and didn’t have any ownership of the change and when that happens a team’s performance will be suboptimal. Yeah, I could use the excuse that my senior management dictated what they wanted and I could drum up a bunch of other excuses but the fact of the matter is I should have raised a flag with my leadership and encouraged better collaboration for input from the engineers, QA testers, product managers, and others.

There were two key learning points that I was able to take away from my experience. Technology leaders should ask themselves two simple questions before they start to drive change in their organizations.

1) How do I make sure that my team has input and ownership of the change we are about to make?

Sit down with the team and work with them on coming up with solutions and their recommended timing. Engineers love to problem solve and they are very good at it. Provide the team with the problem that needs solved and any constraints and let them determine the solution. For example, in the situation I described above, we needed to improve our time to market. Many products and features across the organization were being delivered late, payloads for deployments were too big, and the business was frustrated. As on overall company we decided that we would adopt Agile utilizing Scrum practices but there were still many problems that needed to be solved. Those included determining a branching strategy, determining a deployment strategy, identifying how to measure a sprints performance, and many others. By providing the context of why changes need to be made, the team will recognize the significance of their input and by allowing them to come up with solutions they will feel empowered and have ownership in the game. All of this will help you to create a higher performing engineering team.

2) What do I need to do as a leader to establish guardrails in my organization and sustain the change as my company grows?

Once the team has determined how to solve some of the problems, you will want to make sure that you sustain them in your organization. To do this, work with them to establish documented guardrails or principles that be used as the what. For example, the Agile Manifesto essentially identifies principles that you can use. One principle could be “Business people and developers must work together daily throughout the project.” This describes a behavior that’s needed but doesn’t identify how. The team can decide the specifics on how they will achieve the principle. We at AKF believe in establishing architectural and scaling principles that are essentially guardrails as well. (Visit our earlier blog on architectural principles for more details.) For example, Rule Number 39 – Ensure You Can Wire on and Off Functions in our book Scalability Rules identifies the need to have a framework where you can quickly disable and enable features to minimize impact to customers when a failure occurs. You can solve this many ways and your engineers can determine what the solution should be. Once your principles are established you should monitor them to make sure they are being upheld and reward results.

If you ask yourself these two simple questions before diving into a big change your road to success will be much easier. Now that you have empowered your team to determine how to solve the problem and you have documented your principles and guardrails, the team should be able to operate within them and make decisions on their own. In turn, you will find that they feel empowered and you will have helped to create and maintain a higher performing team.


1 comment

11 Leadership Principles – Part II

This is a continuation post from last week where we covered the first six leadership principles from the perspective of a technology leader. In this post we’ll cover the remaining five principles.

7) Keep your soldiers informed – In the military the headquarter staff makes an overall plan for a mission, presents the plan to subordinate units, and lets them plan the details of how to execute. This planning hierarch can occur across many levels such as starting from the Division HQ, then to the Brigade HQ, then to the Battalion HQ, then to the Company, the Platoon, and finally to the Squad. All this planning takes time but each subordinate plan requires information from the higher plan. You can imagine that with all this planning you could quickly run out of time to actually perform the mission, assuming it is time sensitive, which most things in life and business are. The rule of thumb that we used as a staff in the military was to take 1/3 of the remaining time to put your plan together and leave 2/3 for your subordinates. If we the Division staff had 1 week prior to the mission they would take 2.3 days to develop their plan, leaving 4.7 days remaining. The Brigade would use 1.5 days, leaving 3.2 days. The Battalion would use 1 day, leaving 3.1. The Company would use 0.7 days, leaving 2.1, the Platoon 0.5 day, leaving 1.4, the Squad 0.3 day, leaving 0.9. This same concept should apply to your teams. Don’t sit on ideas, contracts, or problems for 3/4 of the time before it is due and make your team scramble. Give your teams the majority of the time to plan and execute. Reiterating from principle #3, make sound and timely decisions. Taking up all the time so that you get 95% of the information before you make a decision is being a whimp. Gather the most pertinent data, make the best decision and make sure your team gets as much time to react as possible.

8) Develop a sense of responsibility in your subordinates – This principle is a combination of #2 “Seek responsibility and take responsibility for your actions” and #4 “Set the Example”. If you seek responsibility for your actions and set the example for your team, they will follow and behave the same way. For a technology leader, this might manifest itself in a situation where you expect your subordinates to admit when they changed the production environment without approval resulting in an incident. You should expect and demand this behavior from your team but you first must ensure that you are’re taking responsibility for your own actions. Instill in your team a sense of ownership over the site. In order to do so you need to set the example of owning the business. Blaming the business leaders for poor decisions and expecting your team to take responsibility for the technology will never work. Create a culture where people want to own their areas and do so by owning yours.

9) Ensure that the task is understood, supervised and accomplished – There is a big difference between micromanaging and providing adequate guidance on a project. Per principle #2 “Seek responsibility and take responsibility for your actions”, you can’t delegate your responsibility only your authority. Miscommunication is probably the single biggest cause of rework. Clear, concise, articulate criteria are the way to ensure tasks are started properly and accomplished. If you assign an unclear task without a deadline and without guidance on resources you can expect it to come in over budget, after the deadline, and not accurately completed. Communication of the task is your responsibility. In military aircraft we used a three-way positive transfer of control. This meant that if I were flying and I wanted by co-pilot to fly I would say “you have the controls”, they would respond with “I have the controls”, and I would reiterate “you have the controls.” This way there was very little chance of no one actually flying the aircraft…which in tandem seat aircraft you’d be surprised how easy that can occur.

10) Build the team – As a leader you must be constantly building the team. This doesn’t always mean hiring more engineers. Building the team can take the shape of improving their skill sets or replacing underperforming individuals. We’ve written before about seed-feed-weed-succeed. This simple garden analogy means that you need to hire (seed) the team with great players, grow (feed) them through challenging projects, greater responsibility, and training, get rid of (weed) underperformers once they’ve had a chance to improve, and by doing these three things well you and your teams will succeed.

11) Employ your unit in accordance with its capabilities – This last principle requires that you first follow principle #5 “know your soldiers and look out for their welfare.” In order to deploy or ask your team to take on certain projects, you need to first know what their capabilities are as a team and as individuals. If your team is newly formed, you probably don’t want to take on critical projects for major customers. If you don’t have anyone who knows databases you don’t want to architect a DB heavy application. Setting your team up for failure is not what leaders do but you won’t know if you’re doing that unless you know your team and the team members.


Comments Off on 11 Leadership Principles – Part II

11 Leadership Principles – Part I

In several previous posts, I’ve referenced a set of 11 leadership principles that I was taught in the military many years ago. These are apparently still in use by the Marine Corps and studied by the Air Force. As appropriate as they were for leading small units, they have also served me well in many other roles. No doubt you’ll quickly see the relevance these principles have to a military leader but to a technology leader you might balk. In this post I want to cover them using the lens of a technology leader. I think they are extremely relevant to all leaders and might help you either improve yourself or coach a rising star in your organization. I’ll start with the first six this week and finish up the remaining five in next week’s post.

1) Know yourself and seek self-improvement – In no other discipline, that I can think of, are practitioners and scholars faced with more rapid change than information technology. Not only is the underlying technology rapidly changing and sub-disiplines, like scalability, evolving but entire business models are being made obsolete to make way for new models. As technologist, we must all constantly improve and the first step down that path is to know your own limitations. Too often we run into technologist, usually men…but that’s another post, who think they know everything there is to know. Even if that were true this morning by tonight they would be behind in their knowledge.

2) Be technically and tactically proficient – I’ve covered this several times before in other posts but its worth repeating. To be a great technology leader you need to understand the technology. Your team will respect your opinions more and you won’t have to run back to your architect to answer questions raised by your peers. If you don’t know how to code or setup a database or haven’t done it in a while, start this weekend on a project that will require you to learn hands on about your chosen profession.

3) Seek responsibility and take responsibility for your actions – There is a passage in The Art of Scalability that reads “You can delegate anything you would like, but you can never delegate the accountability for results.” I can’t think of a more concise way to say this, you as the leader are responsible, period…end of the story.

4) Make sound and timely decisions – We are proponents of data driven decisions and have seen many times in our careers where someone’s world-class opinion about a product feature turned out to be completely wrong. However, analysis-paralysis occurs every day, even in small startups where you would think there wouldn’t be such an issue. Use the Pareto principle. Gather the 20% of information that makes 80% of the impact, make a decision and execute. The entire point of the Agile methodology, that almost all technologist are fans of, is to admit that we don’t know. The correct way to get there isn’t thinking long and hard about stuff but rather make things happen and see the results in order to make course corrections for the next iteration.

5) Set the example – You’re probably familiar with the proverb that a fish rots from the head. Organizations, whether government, monarchies, military, or tech startups, are the same. A leader who lies or has a poor work ethic will quickly have a team that imitates their shortfalls. Arrive earlier, leave later, work harder. Show more passion, more grace, and more thankfulness for your employees. Act like the leader you want to be led by and you’ll have an amazing team that will follow you anywhere.

6) Know your soldiers and look out for their welfare – Similar to the principle above, in order to led well over the long term, you need to build a relationship with your team by getting to know them and letting them get to know you. I’m incredibly private and reserved but you have to open up some in order to let peers and subordinates know that you’re human. Once you know your team members, their capabilities, their fears, their hopes, their dreams…look out for them. This means helping them become the manager they want to become or help them earn the promotion or pay raise they desire. Put them in positions that will stretch them but don’t leave them hanging without a safety net. A good leader gives team members opportunities to succeed or fail. A great leader puts team members in positions where they can succeed or fail but makes sure they catch them if they fall. I relate this to teaching a child how to ride a bike without training wheels. If the child feels you holding them they don’t build the confidence they need to do it themselves. If you don’t keep a close hand they might fall and hurt themselves, which will make them shy away from wanting to learn. The perfect combination is far enough away to make them feel like they could fall but close enough to catch them.


1 comment