Engineering MBA - The Proposal

Abstract 🔗

Improve your work as a developer with an introduction to strategic planning, situational leadership, and process management. No balance sheets or income statements here; join me to learn the MBA skills valuable to developers without the opportunity costs of lost wages or additional student loans.

Demystify the strategic frameworks your management team may use to make decisions and learn how you can use those same concepts in your daily work. Explore the synergy one developer achieved by going to business school (sorry, the synergy comment slipped out - old habit).

Details 🔗

The purpose of this talk is to introduce key concepts from an MBA program that have proven valuable to me as a software developer. These aren’t focused on tools to help you start your own business, or run your own department as a manager. There will be no math, no financial models, and no marketing plans. These topics are items that I learned during my MBA curriculum that I put to use in my day-to-day work as an individual contributor developer.

For each of these, I’ll introduce the topic and then explain how it’s applicable to developers.

Situational Leadership 🔗

Introduction 🔗

Different tasks call for different leadership styles, and an effective team or leader can adapt their style as needed. Based on both the assignment and the people involved, the support, guidance, and process required to complete the work should vary. The Situational Leadership model, first introduced in “Management of Organizational Behavior”, suggests four different leadership styles.

Directing 🔗

Directing is considered the formative stage of leadership, where the team or individuals may not have much context to navigate independently in a successful manner, like if one is new to a team. Even if someone has been on a team for a long time, the directing style can be beneficial if the work is new (or unfamiliar), but can be accomplished by following a recipe. When using this style in creating a ticket to be added to the sprint, ensure it contains a clearly defined set of instructions for what to do. If work is assigned to particular individuals during sprint planning, ensure there’s a second member assigned to this work, someone who has done something similar before, so that they can work together and learn from each other to accomplish the goal.

Coaching 🔗

Rather than following a recipe, as in the directing style, when coaching, instructions may still be required to lead to a successful outcome, but they are better structured as suggestions or a jumping off point. This gives the person assigned the task the freedom, and encouragement, to put their own spin on the work. Find past examples of solutions to similar problems in the past, and link to them in the ticket. The purpose is not to enforce or take the stance that these things are the same and should be the same. Instead, point out that investigation should be conducted by the team working on it to determine how similar these tickets are and what applicability the other solution has to this current task.

Supporting 🔗

When team members have relevant experience to complete the work successfully, but may be missing the self-confidence to deliver the work, a supporting leadership style may aid the task while also benefiting the growth of the team member. It’s unlikely, but still encouraged if felt necessary by the team member, to have an upfront conversation about implementation details on how to complete the task. Instead, daily standup or other natural touchpoints are a better opportunity to help finish the task. The team member may be better helped by checking in on how they’re feeling about the work and providing them ample time to talk with you about their progress or any issues they’ve come across.

Delegating 🔗

The delegation leadership style is best applied for a team member who is both highly motivated and very skilled in the particular task. The need for supervision is minimal, and the primary delegation task for the leader is to get out of the way and clear any impediments the team member may have. That is, of course, a component in all of these styles, but it is essentially all that’s left in this stage.

Most importantly, this is an opportunity to pull other team members forward on this continuum with this task. Should it be a safe opportunity to do so, where there aren’t intense time pressures or other risk factors, this is absolutely when the experienced person assigned to this work should be working alongside a less familiar colleague to share their knowledge and expertise, for the benefit of all.

Developer Applicability 🔗

Thinking through these styles can be helpful when engaged in sprint planning meetings or backlog refinement/grooming sessions. Situational Leadership can be used to determine how to parcel out, organize, or describe the work to be done. It’s important to note that it’s not sufficient to use one particular style, even towards a specific team member, for all units of work. A team member may be able to be left alone and faithfully execute one task, where the delegation style will work best. That same team member may be completely unfamiliar with another aspect of the project, where the directing style will be most helpful.

In order to round out the familiarity amongst the team with areas of the application or technical concepts, certain work may be recommended for particular team members, with the knowledge and understanding that the appropriate support is required. However, if there is a time-sensitive or extremely important unit of work that must be addressed, it may be more appropriate to play to the strengths (and familiarity) of a team member who recently worked in that space to complete the ticket.

Situational Leadership dynamics can also play out in pairing sessions. If you’re able to ascertain your pair’s comfort with a particular task, you can use that information to shape the pairing session to meet everyone’s needs. For example, someone completely new to a topic may not have the context to navigate around the area being worked on, so while the Situational Leadership model would suggest a “Directing” style, in a pairing session, that may manifest itself more like a “Tour Guide” where the pair with more context provides the background and story for the work being completed while driving themselves, and allowing ample time for questions and clarification as the task is moved through - along with plenty of opportunity for interactivity, allowing the other pair to build up their familiarity with the work being done.

Competitive Advantage 🔗

Introduction 🔗

Your competitive advantage, a concept largely attributed to the work of Michael Porter, is what sets you apart from others. This section will discuss the “generic” strategies to achieving a competitive advantage.

A core competency is part of what drives your competitive advantage, and your efforts should be focused on maximizing effort spent there while minimizing effort elsewhere. Core competency is a term that was popularized thanks to the work of Prahalad and Hamel.

Cost 🔗

The most obvious strategy, but least sustainable over the long-term, is to be the lowest-cost provider. This may be feasible if you can reliably produce your product or offering in a way that competitors cannot, or if you have a massive VC runway and raised a sizable round of investment. This is also the easiest strategy to replicate. Firms employing this strategy must be careful not to be driven to a race to the bottom, at which point there is no cost advantage and another strategy is the only way to succeed long-term. If we were building a blogging platform, then to have cost be a competitive advantage, you would need to sell your product cheaper than any other competitor.

Differentiation 🔗

If one is intentionally operating in a way that is unique in the landscape, they are looking to capitalize on the competitive advantage of differentiation. This highlights certain compelling or important characteristics for potential customers and accentuates your ability to deliver on those items. To further our blogging platform example, this may be a concierge service that automatically (at least in the eyes of the customer) brings in any writing the customer has already done and imports it onto the new platform. The blog company may be able to charge a premium for that service, and attract more customers, if it meets the needs of customers in ways that other platforms do not.

Focus 🔗

The focus strategy tends to manifest itself by identifying a particular segment of the market and tailoring an offering that’s specific to those customers. For example, the blogging platform may focus on doctors by building a feature that provides a comment moderation system which scans text for possible HIPAA violations and holds comments in a temporary queue until they’ve been approved. If you’re not a doctor or a healthcare worker, that feature may not be valued very highly in your decision of blogging platform (though hopefully it’s something you can appreciate); however, if you are a doctor, that can be a deciding factor in your choice of which platform to start your blog on.

Developer Applicability 🔗

If you’re building functionality to send a user an email and your application happens to be an email delivery service, then it’s (hopefully) in the best interests of the company to be writing and using your own software to manage all the infrastructure and processes involved with sending an email. However, if that is not your company’s business, then you’re likely much better off relying on a company that focuses on email delivery and focusing your custom development on the areas that are truly unique about your organization.

Process Management 🔗

Introduction 🔗

Identifying and proposing informed changes that help achieve our goals for our products, our companies, and our daily lives is critical to facilitate continuous improvement. Business Process Reengineering is the strategy of documenting the current state of different processes and critically evaluating the value of each step to propose a more streamlined future process. Michael Hammer is credited with developing this work.

Developer Applicability 🔗

Developers are continually introducing and refining processes for their end users; we call them features. Managing, benchmarking, and refining these processes can be critical to the success or failure of an overall product.

More personally, we all have our particular workflows we follow. By evaluating our tools or the steps we take to deliver our work, we may become more efficient and eliminate what Business Process Reengineering practitioners may call “wasteful” or “low-value” activities. For example, when interacting with git, this may mean writing new aliases for commonly-used commands, learning different shortcuts, using a different git client entirely, or learning to eliminate the need for entire commands, like using git pull rather than git fetch and git merge.

Pitch 🔗

After two years spent earning an MBA full-time, I returned to the workforce just as I left it: a software developer. The knowledge I gained over those two years is much more applicable to my day-to-day work as a software developer than I ever thought it would be.

An MBA mindset helps developers solve problems up and down a company’s management structure. It gives you the tools to assist the management team in making tradeoff decisions between projects, and also more perspective on why that piece of code you’re writing is so important to the company’s success.

Speaker Information 🔗

Kevin utilizes the knowledge learned as a business school graduate every day as a software developer. As proof of how great at business he is, he’s giving all of this information away: for free.

Kevin lives near Boston where he is a Software Developer at The Gnar Company.