Leadership, Technical, and Human

Technology isn’t just about the technical. Not by a long shot. It starts and ends with people.

Of course technical expertise is required, no doubt. But why do so many technology projects end in disappointment or debacle even when the technical side of the equation is well covered?

The answer is that the technical is only one side of the equation, and — especially internally to an organization — not even the most critical side.

The types of work required to maintain a healthy, effective technology ecosystem — whether small, simple, and constrained or large, complex, and ambitious — cover a much broader range of responsibilities than often expected, from “leadership” to “technical” to “human”. Each is critical to your success, and none can be overlooked.

Technical is the most easily understood, so let’s explore the other two points on the triangle.

HUMAN

When it comes to the “human” side of your technology, everyone knows that training is an essential piece of the puzzle. But the typical mechanisms for training around technology fall far short of a realistic plan for successful technology adoption. There’s a reason people don’t tend to feel particularly reassured after the typical training or two.

What does it take for someone to get really comfortable with using a system, and to know how to use it in the right way? It takes training and more training, exposure and use, running into questions, and an incredibly accessible, consistent level of support. And we’re not talking about the “please submit a ticket” kind of support. We’re talking about the friendly and accessible kind of support that views questions and inquiries and ideas as valuable invitations to help, assist, and learn. The kind of “human” ally-ship that recognizes that we’re all on the same team, and the better you use and understand the technology, the better our collective work will be.

Just as critically, this kind of all-out, ally-minded support creates a symbiotic situation where the insights and understanding gathered from that level of human support allows the product team to gather and prioritize fixes and opportunities for improvement at an entirely different level.

If you’re simply triaging bug requests, you’ll never be able to understand the living pulse of your technology and its intersection with the real work being done. But if you’re out there, supporting the living hell out of people, you’ll soon gather an invaluable level of context and understanding about the strengths and shortcomings of your technology as it’s actually being used, and that knowledge can be fed back into making it ever more valuable, helpful, and impactful.

LEADERSHIP

Probably the most critical — and often the most overlooked — side of the equation when it comes to successful technology is the realm of “leadership”. This includes the critical responsibilities associated with steering the ship through ever-changing waters and nearly unlimited potential destinations.

One key area of that leadership is the work of product management itself. The core responsibility of the product manager is charting a clear roadmap for the product’s development and maintenance, balancing needs, ambitions, priorities, and constraints into a coherent path forward.

There are many nuances to be said about the particulars of maintaining a product roadmap, but big picture it’s easy to understand why organizations who lack a clear roadmap tend to feel their product floats along adrift, full of frustration points and falling far short of its potential to support and enhance their work.

Equally as critical in the realm of leadership are key responsibilities that require excellent communication skills and a deft human touch, such as driving diplomacy, buy-in, and understanding among stakeholders and users around the organization and beyond.

Then, throw in all of the other common leadership functions such as budgeting, careful and detailed management of a team, and engaging and maintaining the consultant relationships, and you have a whopper of a critical area of responsibility -- often underestimated or neglected but absolutely essential to the success of the overall system.

~

Stepping back and looking at these three critical areas -- leadership, technical, and human -- it’s evident how neglecting any one of them will result in critical pieces getting dropped. All three must be covered at a high level. So it’s no surprise that technology efforts that try to throw only technical expertise at the problem often come up so far short.

Looking at these three areas you can also readily understand how it’s asking a lot to try to put all of those duties on a single person. Typically people’s skills and especially interests lie at one side or the other. So you generally do well to focus different members of the product team on the areas where their strengths and interests lie. Learn much more about how to staff and structure those roles in our white paper, Resourcing Your Salesforce CRM Product Team.

Back to the Curriculum page

The Platforms Chief: "Protector of the Realm" and "Greatmaker"

The platforms team needs a chief. A great chief. A steward and protector, a guide and a field general. Every role on the team is important, but getting the right person steering the ship will differentiate whether the platforms team becomes an organizational gamechanger or just spends its time fixing things.

We’ve helped set this role up under several different names, and we’re not too picky about the title. That said, we’re very selective about the person. You need someone terrific steering the ship — someone who truly ‘gets it’.

There are two sides to the chief role. We call those sides the “Protector of the Realm” and the “Greatmaker”. Most of the time they are part of the same person’s role, but at a certain scale those two roles can also be held by a chief and a deputy.

Protector of the Realm

The bottom line for the “Protector of the Realm” side of the chief role is ensuring there is a healthy, two-way communication line between the organization’s priorities and the platform team’s capacity to execute. It is critical that the chief sits at the organization's leadership level in order to play this role. 

Before the chief was part of the leadership team, the organization would set strategy and make critical planning decisions without a clear understanding of its own capacity to execute given its technology landscape. The leadership team probably already had representation from Programs, Development, Marketing/Communications, and Operations. But as far as technology was concerned, directives would come rolling down the hill fully formed and without warning, often scrambling best laid plans, pulling the rug out from under longer term investments in motion, and sometimes dictating near term project timelines that were impossible to meet with any level of quality.

With the chief on the leadership team, it’s a different story. While organizational leadership is setting strategy and plans, it has the benefit of someone there who understands exactly what the organization is capable of from a technology standpoint, and on what timeline. The product chief can also keep an ear to the ground across the organization to close important communication loops, prevent problems before they take root, and align cross-organizational strategy with cross-organizational execution. 

Meanwhile, with the platforms chief in place at the leadership level, the platform team itself can do more effective and targeted work with the benefit of absolute clarity on the organization’s priorities and plans. They have the perspective needed to prioritize the most effective mix of longer term investments to strengthen the organization's technology foundation, together with more immediate or urgent projects.

Finally, leadership now includes the voice it needs to make clear the costs of neglecting key elements of its technology infrastructure, which otherwise only tends to happen once the levee breaks. The price of this awareness ends up being a drop in the bucket compared to the cost of cleaning up the mess later.

The Greatmaker

The other side of the chief role involves acting as “The Greatmaker” for the platform team’s work, meaning they are the person responsible for raising the level of the team’s game from merely good to outstanding. When it comes to the organization’s technology platforms, there will never be an end to the list of possible fixes, interventions, and ideas. So the entire ballgame comes down to a magical mix of the right set of prioritizations, the right people on the job, and the right mid-game adjustments.

It can be hard to pin down exactly where and when a skilled Greatmaker is raising the level of their team, but it’s always happening. You’ll see this person elevating good ideas from the team, helping act as a sounding board and thought partner for product managers, asking for the simplified, not-overly-technical reasoning behind a expert recommendation, helping tweak draft priority lists to more squarely hit their targets, and following instincts on when extra communication across departments is needed, to name just a few examples. 

Perhaps most importantly, the Greatmaker is a skilled and collaborative leader of people, who recognizes and appreciates their talents and interests, and who helps draw great work from them by creating an atmosphere of trust, humility, and expert helpfulness. They align excitement with opportunity, finding just the right people to geek out on just what the organization needs figured out, just at the right time. There’s a willingness to get into the details, to slow down when appropriate, not rush to a decision when complications are relevant, to hear everyone out, and to make lean, targeted bets to help learn what’s needed to sharpen the plan. 

Finally, the Greatmaker also isn’t simply satisfied with a slick build. This person knows that much more important for realizing the potential of the investment is the extent to which people (staff or external constituents) truly know how to take advantage of the platform. This requires an all-out ethos of communication and support that goes well beyond setting up a few trainings, but actually gets the product team on the playing field every day, working closely with their colleagues to deliver on the organization's mission.

Above all, the Greatmaker has excellent judgment. How? It’s hard to say, exactly. Greatmaking is a magical mix of skills that can’t easily be taught. But once you know what you're looking for you can recognize and nurture someone with the right raw materials. 

So what’s the profile?

As with many of the hires we recommend, the profile for this role may differ from what many organizations might expect. You’re not looking for a traditional CTO or CIO. Extreme technical depth is not the key skillset here. Sure, you benefit from someone with enough technical proficiency to dive to just enough depth to understand the tradeoffs of one path versus another. And yes, they need to be a systems thinker of the highest caliber.

But the key skillsets here are leadership, communication, and diplomacy, mixed with that special magic that allows someone to elevate a team to greatness. The right person may already be in your organization, in a different role, with their full potential waiting to be unleashed. Sometimes the right person can be elevated from one of the Product Manager roles — regardless of whether they have depth in each of the team's specific technologies — especially when they have already shown they excel at the types of skills and instincts required.

And when this person is hired externally, they need to be nothing short of fantastic. You as an organization need to be clear-eyed about who you are recruiting and what you are screening for, to be willing both to wait for the right person, and then to really set them up to succeed.

You don’t need the fancy tech genius, the IT whiz, or the ace developer. Those are all probably the wrong fit. You want the person who will both be right at home in your leadership team as "Protector of the Realm" of your technology, and who has the mix of "Greatmaker" qualities needed to raise your entire platform team of can-do problem-solvers and make-betterers — and with them your entire organization — to an entirely new level.

Back to the Curriculum page

Put the Chief on Your Leadership Team

A fully-realized chief of the technology accelerator team (a.k.a. product team) is an executive team level position. Not having that voice on your leadership team is part of why your organization has been so consistently stumbling when it comes to its technology.

If it sounds outlandish to put the product chief role on your executive team level, that may be an indication that you’re still viewing your technology as an I.T.-level operations or service function, rather than a highly consequential, ever changing strategic challenge that will continually set direction for the entire organization.

Before you had this role on the leadership team, your organization was making strategic decisions, forming plans, and assigning priorities, probably with near total disconnect from its ability to execute on them from a technology standpoint. You likely had representation from most other key stakeholders. Program could weigh in about the complexities of its upcoming calendar. Fundraising could speak about how to leverage the opportunities ahead. Communications resolve questions around relative priorities as decisions were weighed.

But when it came to technology, it felt like sort of a black box. 

Now, once your chief is on the leadership team, you’re connecting your organization’s strategy and decision-making with its ability to execute in the real world. Now you’re setting strategy, goals, and timelines with a realistic sense of capacity and capability in the mix. Now you’re securing resources and staff at a realistic level to help technology initiatives deliver on their game-changing level of promise, instead of feeling hostage to a series of poorly-understood proposals and price tags that have been passed up the chain. Now you’re putting a strong organizational voice behind the bet that being able to harness the power and promise of technology is an essential ingredient for your organization to realize its potential.

Of course, this doesn’t mean you should just grab your IT person or a regular junior leaguer and stick them on the executive team. You should care about this hire just as much as a COO, a Development Director, or a Communications Director. You want someone with the ability to hold down a role with extreme competence and clear authority. You want a protector of the realm and a greatmaker. 

But once you have one, the benefits of having that role in the leadership team will become quickly apparent. Put a skilled leader in charge of your product team, include that role in your leadership team, and give your organization a shot to become great at using technology to extend its impact.

Back to the Curriculum page

Flood the Zone with User Support

Many product managers probably spend a majority of their time and energy focused on what to build next, and relatively less energy on supporting people to use what is already built.

But is there any better investment than making sure what you’ve built is being used to its fullest potential? 

That’s because the people who use your platforms and products are the most important piece of the puzzle. It doesn’t matter how great a system is if it’s not used to its potential to accomplish its tactical goal. Cranking out a bunch of innovation that doesn’t get fully used doesn’t do your organization much good.

You need your systems to be well understood and well used. And to get there you need to “flood the zone” with training and support. 

Sure, iterating and developing the tool itself is a central part of the job for your technology accelerator team. But equally if not more important is an all-out, ally-minded dedication to ensuring that people have as much support as they need to use the existing capabilities. Such much so that when we’re building a team, we often fill an explicitly support-oriented role even before filling a more technical role.

When done well, this kind of support often looks much more casual than formal. It’s part of the relationship building you do all the time. 

People don’t just attend a couple trainings and then remember everything they need to know from there forward. That’s not how it really works, right? People need constant support, clarification, and reminders — in context -— as they’re trying to accomplish the work itself.

And by providing that level of support,  you’ll be getting as much help with your job as they will be getting help with theirs. Because to improve your systems you need constant feedback about what people’s challenges are,  what’s working well, and what could be improved. 

You’ve designed a racecar, and customized it for the race, and the expert drivers take it around the track and tell you how it feels. You make further adjustments, they take it out again, and on and on. You’re also watching them circle the track and noting things from your perspective, things they might not notice themselves about their own usage, you may see some slipping around the corner and know just how to tighten that up. You are not an inexperienced order taker here, you’re an expert engineer with experience and ideas about how to make things better. But you need to be there, watching them work, in order to bring this experience to bear. The cycle never stops, though the improvements get more and more precise, eventually addressing every aspect of the race. 

You can’t race the car for them. They need you to be thinking about new ways to make the engine more efficient and powerful, or new ways to make the shape a bit more optimally aerodynamic. But you can’t do this hiding behind a ticket queue, you have to get out there and be a part of the race, ready to jump in and help however is needed.

So don’t begrudgingly offer support around the edges. And don’t wait until people seek you out, or you’ll miss 80% of the useful stuff and 80% of the chance to make an impact. Flood the zone with user support! Every repetition you get out there on the field will make your users more confident, more secure, and give you constant reminders about what the actual priorities are.

Back to the Curriculum page

Get Out From Behind Your Ticketing Queue

Photo by Mimi Thian

A couple years ago I tore up my knee playing softball. It wasn’t super glorious, although I’m still grateful that we live in a day and age where they could take a ruined knee and make it work again. That still seems like an utter miracle.

That said, the long road back from injury included a staggering number of physical therapy appointments over the course of two years — at times as many as three times a week. 

To schedule each appointment, after I was done with the previous session I would walk out past the reception area and schedule the next one. It didn’t take long to realize that there was a serious issue with the scheduling software. 

Stephanie — who was relentlessly nice about it — would have to re-start from the beginning for each different physical therapist whose schedule she wanted to check. She would find a possible time for me with one therapist, then start over, try a different therapist, and find a comparison time. It took a shocking amount of typing and clicking to be able to say “Kathleen has a 3:15 on Wednesday. Now let me start over and check Randy’s schedule…” 

Often she would check the schedule like this for 4-5 different therapists in order to schedule one appointment. And that process happened 3 times a week just for me, but probably many thousands of times a week for all of the patients coming by her desk. What an atrocious use of Stephanie’s time and energy.

How Stephanie didn’t hurl her computer out the window is truly a mystery to me.

When you witness a situation like this, it’s pretty clear that no one on the software development team has spent much time hanging out at Stephanie’s desk, just watching her use the system they built. If they did, they would have 15 different ideas of things to improve within the first hour. And one of those ideas just might save the hospital system about 100,000 staff hours over the next year.

But chances are, someone in the IT or software team has come by at various times to fix an issue Stephanie submitted as a help ticket. Maybe they even fixed it, solved her problem, and left her happy. 

That’s great. But it’s not the same.

If you really want to improve your technology tools and systems, you have to get out from behind your ticketing queue. Ask people if you can watch them use that new feature at some point. Offer to help show them that thing again from the training at a time when they will actually need to use it. Check back in about how that event went, if they were able to enter the new contacts in, and whether they had any problems or ideas on how to improve it for next time.

If you really want your system to fulfill its potential as a gamechanger, get off your rear and get in the game.

Back to the Curriculum page